IPSec nat question

RouterOS General
1

Hi, I’m new to mikrotik and need some help with an IPSec VPN.

I’ve phase 2 with established connection to the site B (Fortigate) but can’t reach the other site.

I’m required to use following ACLs:

Site B: 10.2.20.27/32
Our Site: 172.34.33.188/29

I’m also required to nat our LAN at origin with the following IP: 172.34.33.189 before sending the traffic through the tunnel.

So far for the IPSec config at our Mikrotik I’ve used for the policies Src-Address: 172.34.33.188/29 and dst-address: 10.2.20.27.
With this config I have established phase 1 and 2 correctly but I’m not sure how to continue with the Firewall/Nat and Filter rules needed for this approach I’m required. As additional information, we have fastback enabled.

Thank you all for your help.

2

It looks like you want this:

/ip firewall nat
add chain=srcnat dst-address=10.2.20.27 action=src-nat to-addresses=172.34.33.189
3

Sob, thank you for your answer.

Just added your rule. Placed it on top of them, before this rule:

chain=srcnat action=accept src-address=172.34.33.188/29 dst-address=10.2.20.27

Is this rule correct? I’ve tried using both of them, I can see packets hit on your rule but nothing on the accept rule, so I guess my pings are leaving through the wan masquerade and not through the IPSec tunnel.

Thank you for your help.

4

You want one or the other. Yours is to exclude selected traffic from srcnat. Mine is to change source (to 172.34.33.189) of everything destined to 10.2.20.27, at least that’s how I understand the request (it actually seems a bit weird, to add policy for whole /29 and then accept only single address).

5

Thanks for your quick answer.

Ok, I understand…
I just removed my rule, but still don’t have a ping answer. Any other thing I should consider checking?

thank you again for the help

6

Check IP->IPSec->Active Peers, there are counters that should increase when you’re trying to connect to 10.2.20.27. They also show if anything is coming from there. Or you can log packets with:

/ip firewall mangle
add action=log chain=prerouting ipsec-policy=in,ipsec log-prefix=ipsec-in:
add action=log chain=postrouting ipsec-policy=out,ipsec log-prefix=ipsec-out:

If you don’t see any outgoing, check your firewall filter.

7

Ok, great. I have Tx Packets/Bytes increasing, but Rx Packets/Bytes counters both in 0

8

Then either the other side is not sending anything, or something blocks it. If you don’t have NAT, it could be your firewall blocking ESP packets, but stateful firewall should also allow them once you send something. If you do have NAT, IPSec should should use UDP encapsulation, and that should work.

9

Thanks Sob for the answer.

I have the firewall filter rule

chain=input action=accept protocol=ipsec-esp in-interface-list=WAN log=no 
      log-prefix=""

This one has hits while making the tests (and also the other counters increase at the same time)

10

Other counters are peer’s rx counters, of they are still zero? ESP packets carry data in tunnel, so if you see incoming ESP packets, I’d expect something showing in peer’s rx counters too.

You can check if there’s perhaps some hint in IPSec logs (/system logging add topics=ipsec), but unfortunately they tend to be not very clear and very long.

11

They still in zero.
The ESP packets only increase when I try outgoing, I don’t see any incoming ESP, neither any incoming packets on the IPSec>Active Peers tab

12

The rule you posted in previous post is in chain=input, that’s incoming traffic to router.

13

Ok. I see. So there’s incoming traffic, but under Active Peers empty, that’s what needs to be fixed?

14

Yes, but router clearly gets something, so the question is why it doesn’t like it. Are you absolutely sure that what you got is correct? I mean this:

I tried quick test with non-matching policies where on one side I used smaller remote subnet, than the other side had as local one. I got phase 2, everything looked ok, but when remote side sent packet from source that it thought it can send, but local side didn’t have it as alowed, it behaved exactly as you see it, there were incoming ESP packets, but zero rx for peer.

15

Yes, that’s what is stated in the requirements

The Interesting traffic to configure in your firewall must be applied as indicated below:
-The network segment 172.34.33.188/29 as your “local address” of the IPSec VPN
-The IP address 10.2.20.27/32 as the “remote address” of the IPSec VPN

Important:
By internal policy, to avoid incurring private IP overlaps:
“It is not allowed to use in the IPSec tunnel the addressing corresponding to your LAN network”

NAT
As described above, you must use the following IP 172.34.33.189 (first available host of the previous network), to perform a “NAT at the origin” of your LAN network and then send the traffic through the IPSec VPN

16

I don’t know. I still don’t understand why there’s /29 when you should use only one address (with NAT), but otherwise I understand it the same way, i.e. that you should have policy for 172.34.33.188/29 ↔ 10.2.20.27/32. For the lack of better ideas, as a test I’d try to use 10.0.0.0/8 for the remote side, to see if it changes anything for incoming ESP packets and peer’s rx. Or you can try to export and post your config, if perhaps some mistake is there, but I’m not sure what it could be.

17 
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-128,3des
add dh-group=modp1536 enc-algorithm=aes-128 name=CONE
/ip ipsec peer
add address=xxx.xxx.xxx.xxx/32 exchange-mode=ike2 name=CONE passive=yes \
    profile=CONE
/ip ipsec proposal
add enc-algorithms=aes-128-cbc lifetime=1h name=CONE pfs-group=modp1536
/ip firewall filter
add action=accept chain=input comment="Echo request - Ping Flood" \
    icmp-options=8:0 limit=1,5:packet protocol=icmp
add action=accept chain=input comment="Echo reply" icmp-options=0:0 protocol=\
    icmp
add action=drop chain=input comment="Drop ICMP" protocol=icmp
add action=fasttrack-connection chain=forward comment=FastTrack \
    connection-state=established,related
add action=accept chain=forward comment=\
    "Accept Established/Related connections" connection-state=\
    established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid \
    log-prefix=Drop-invalid-fwd
add action=accept chain=input comment=\
    "Accept Established/Related connections" connection-state=\
    established,related
add action=drop chain=input comment="Drop invalid" connection-state=invalid \
    log-prefix=Drop-invalid
add action=accept chain=output comment=\
    "Accept Established/Related connections" connection-state=\
    established,related
add action=drop chain=output comment="Drop invalid" connection-state=invalid
add action=accept chain=input comment=Admin dst-port=xxxxx \
    in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="DNS from LAN" dst-port=53 \
    in-interface-list=LAN protocol=udp
add action=accept chain=input comment=L2TP/IPSec dst-port=1701,500,4500 \
    in-interface-list=WAN protocol=udp
add action=accept chain=input comment=IPSec in-interface-list=WAN protocol=\
    ipsec-esp
add action=drop chain=input comment="Drop all Input" log-prefix=DROP-INPUT
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
    protocol=tcp tcp-flags=syn
/ip firewall nat
add action=src-nat chain=srcnat dst-address=10.2.20.27 to-addresses=\
    172.34.33.189
add action=masquerade chain=srcnat out-interface-list=WAN
/ip ipsec identity
add comment=CONE peer=CONE
/ip ipsec policy
add dst-address=10.2.20.27/32 peer=CONE proposal=CONE src-address=\
    172.34.33.188/29 tunnel=yes
18

Disable the FastTrack rule, that should probably help, because FastTrack and IPSec are not compatible. But I’m not sure if it breaks in exactly this way.

19

Thanks for the answer Sob.
Disabled FastTrack, but nothing changed…

20

Then I’m currently out of ideas.