IPSec Tunnel, pingable router but no access

erlinden · Wed Feb 14, 2018 12:11 pm

I have created a site to site vpn connection from home to my parrents, based on this tutorial:
https://blog.pessoft.com/2016/05/29/mik ... s-and-nat/

This works very stable (RB3011 - RB951), though the speed is not really high (which is probably caused by the RB951, which doesn't have a very fast processor), around 20 Mbps. The only problem I run into is that although I can reach all clients behind the router, I am not able to connect to the remote router. Not via WinBox, SSH or web. It does however respond to IGMP. I have no clue where to look at.

Is there a firewall rule blocking this?
My home router firewall looks like this (remote I can't reach at them moment):

/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept established,related" connection-state=\
    established,related
add action=accept chain=input comment="allow l2tp" dst-port=1701,500,4500 in-interface=WAN protocol=udp
add action=accept chain=input in-interface=WAN protocol=ipsec-esp
add chain=forward comment=vpnelcouders dst-address=192.168.50.0/24 in-interface=WAN ipsec-policy=in,ipse
    src-address=192.168.60.0/24
add action=drop chain=input comment="Drop all except for LAN" protocol=tcp src-address=192.168.10.0/24
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=WAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=\
    established,related
add action=drop chain=forward comment="Block guest network except WAN" in-interface=vlan-guest out-inter
    !WAN
add action=drop chain=forward comment="Block video network except LAN" in-interface=vlan-video out-inter
    !bridge1
add action=accept chain=forward comment="defconf: accept established,related" connection-state=\
    established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!d
    connection-state=new in-interface=WAN
/ip firewall nat
add action=accept chain=srcnat comment=vpnelcouders dst-address=192.168.60.0/24 src-address=192.168.50.0
add action=accept chain=dstnat comment=vpnelcouders dst-address=192.168.50.0/24 src-address=192.168.60.0
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=WAN
add action=dst-nat chain=dstnat dst-port=50022 in-interface=WAN protocol=tcp to-addresses=192.168.50.10 
    to-ports=22
add action=masquerade chain=srcnat comment="masq. vpn traffic" src-address=0.89.168.192-255.89.168.192
add action=masquerade chain=srcnat comment="masq. vpn traffic" disabled=yes src-address=192.168.89.0/24

Kraken2k · Wed Feb 14, 2018 4:37 pm

...
add action=masquerade chain=srcnat comment="masq. vpn traffic" src-address=0.89.168.192-255.89.168.192

Isn't this address just written in reverse order? Also the following NAT rule is disabled.

sindy · Wed Feb 14, 2018 10:47 pm

You have placed the rule below to chain "forward" which handles packets transiting through the Mikrotik, so the devices in Mikrotik's LAN subnet are accessible, but you haven't placed a similar rule to chain "input" which handles packets for the Mikrotik itself.

/ip firewall filter
add chain=forward comment=vpnelcouders dst-address=192.168.50.0/24 in-interface=WAN ipsec-policy=in,ipsec src-address=192.168.60.0/24

So put the same rule to chain=input anywhere above the first "drop" one in that chain, and you should be good.

NB - it is a useful habit to keep rules belonging to the same chain grouped together, it simplifies reading them. Mutual order of rules critically matters but only within each chain.

erlinden · Fri Feb 16, 2018 10:05 am

Thanks, works like a charm now! Think I should dive into the world of firewalls a bit more...

sindy · Fri Feb 16, 2018 2:33 pm

I should dive into the world of firewalls a bit more...

If you really mean it, have a look at this and this post.

acruhl · Fri Feb 16, 2018 2:55 pm

That's a pretty cool writeup about doing IPSEC between 2 natted MIkroTik routers. The only part that seems unreliable is this part:

Each MikroTik router has IPSec protocol, NAT-Traversal (4500/UDP) and IPSec IKE (500/UDP) traffic forwarded from its gateway (ISP Router)

I think this is assuming that the "WAN" interface on the MIkroTik routers will always get the same IP address, or there is some other way on these routers to ensure that this traffic always reaches the MikroTik (maybe based on MAC address or something?).

Otherwise it's probably better to just put the MikroTIks on the actual internet connections, use tunnel=no, and do routing between. Much simpler. No firewall rules required, unless you want them of course.

Also, the speed not being high could very well be the upload bandwidth of the ISP, not anything else. My upload bandwidth at my house is all of 2 megabits, and this isn't going to push the CPU on the hAP-lite unless you're using really large key sizes probably.

sindy · Fri Feb 16, 2018 4:04 pm

Each MikroTik router has IPSec protocol, NAT-Traversal (4500/UDP) and IPSec IKE (500/UDP) traffic forwarded from its gateway (ISP Router)
I think this is assuming that the "WAN" interface on the MIkroTik routers will always get the same IP address, or there is some other way on these routers to ensure that this traffic always reaches the MikroTik (maybe based on MAC address or something?).

It is actually enough if the above is true at one end of the connection - remember Archimedes who needed just a single fixed point in the universe

You need to statically port-forward the two UDP ports from the public address to the private one of the Mikrotik, and you either configure that Mikrotik's private address manually on itself or you tell the DHCP server on the other router (or elsewhere) to always assign the same IP address to that Mikrotik's MAC address as you assume.
On the opposite end, the Mikrotik may have a dynamic private address, if you don't mind that the tunnel will fail and re-establish every now and then, and even the public address may be dynamic at that end. The only thing necessary in such case is that the IKE communication is always initiated from this "dynamic end".

Otherwise it's probably better to just put the MikroTIks on the actual internet connections, use tunnel=no, and do routing between.

Yes, having the public address directly on the Mikrotik is the best option, but in the real world, that's often not possible. But it is not mandatory to use tunnel=no in such case, you still can use IPsec tunnel mode if you want even if you do not need it for NAT travesal.

acruhl · Sat Feb 17, 2018 4:23 pm

Each MikroTik router has IPSec protocol, NAT-Traversal (4500/UDP) and IPSec IKE (500/UDP) traffic forwarded from its gateway (ISP Router)
I think this is assuming that the "WAN" interface on the MIkroTik routers will always get the same IP address, or there is some other way on these routers to ensure that this traffic always reaches the MikroTik (maybe based on MAC address or something?).
But it is not mandatory to use tunnel=no in such case, you still can use IPsec tunnel mode if you want even if you do not need it for NAT travesal.

Absolutely. But how many times do you see people mess it up on these forums?

It's easy to make tunnel=yes more complicated than it needs to be based on incorrect assumptions. Which is a widespread issue in these forums unfortunately... (Even me sometimes.)

sindy · Sat Feb 17, 2018 6:43 pm

Each MikroTik router has IPSec protocol, NAT-Traversal (4500/UDP) and IPSec IKE (500/UDP) traffic forwarded from its gateway (ISP Router)
I think this is assuming that the "WAN" interface on the MIkroTik routers will always get the same IP address, or there is some other way on these routers to ensure that this traffic always reaches the MikroTik (maybe based on MAC address or something?).
But it is not mandatory to use tunnel=no in such case, you still can use IPsec tunnel mode if you want even if you do not need it for NAT travesal.
Absolutely. But how many times do you see people mess it up on these forums? It's easy to make tunnel=yes more complicated than it needs to be based on incorrect assumptions. Which is a widespread issue in these forums unfortunately... (Even me sometimes.)

But with tunnel=no at IPsec level, you have to establish some other tunnel (like GRE or EoIP or whatever else) between the public addresses of the two boxes if you want a network-to network VPN, right? Because only packets between these two IPs are handled by IPsec in that case. Or what did you have in mind by "and do routing between"?

acruhl · Sun Feb 18, 2018 6:38 am

Yeah, GRE, IPIP, EoIP, whatever works at that point. You can even use the built in ipsec options on the tunnels themselves to make this super easy.

Since GRE behaves more like point to point links on a "real" router connection, it's more of a lesson in how routing is supposed to be in my opinion. tunnel=yes has it's place, but I think people tend to make it more complicated than it needs to be when using it. It's really a "road warrior" type setup, and there are other possibly better ways to accomplish that.

IPSec Tunnel, pingable router but no access

IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Re: IPSec Tunnel, pingable router but no access

Who is online