We created a VPN Site to site, phase 1 and phase 2 ok. However, I don’t understand how to create the routes.
Subnet A: 172.16.0.0/29
Subnet B: 10.198.8.0/22
What I would like to know is: Does this subnet A need to be on some routerboard interface? Or can I create a route between it and my subnet in use 192.168.0.0/24?
Thanks!
A subnet matching to a policy need not be local, it is enough that there was a route to it.
So the router X, on which subnet A is the src-address of the IPsec policy, must have a regular route to 172.16.0.0/29 via some gateway in its 192.168.0.0/24, and devices in 172.16.0.0/29 must have a route to 10.198.8.0/22 via some gateway in 172.16.0.0/29 that itself has a route there via router X (both may be their default routes).
Also router X must have some route to 10.198.8.0/22 (again it may be the default one) as IPsec policy matching takes place as the very last step of packet processing, just before the packet would be sent out the chosen interface. So if there is no route, the packet never reaches the policy matching stage, and if there is src-nat, the policy may not match the packet.
Sorry for the delay in getting back.
This ipsec vpn was created between a fortigate and mikrotik. From the fortigate side it is possible to access our internal servers, however I cannot ping and telnet to any IP and port on that side.
If “the fortigate side” means one of the two subnets you’ve mentioned in the OP and “our internal servers” means the other one of those two subnets, what you just wrote means that both the IPsec policy and the routing at your side are correct but firewall rules on your devices or on the Fortigate site prevent connections from “your internal side” to “the fortigate side” from establishing. One common omission is that you do not exempt traffic that should get matched by an IPsec policy from getting src-nated - IPsec policy matching takes place as the very last step before the packet would get sent via the out-interface chosen by regular routing. If the only route to the subnet on the Fortigate side is the default one via WAN, the src-nat or masquerade rule changes the source address for connections initiated from your side to the address associated to the WAN interface and the policy thus ignores the packet.
According to the person responsible for the network on the other side, there is nothing in the logs with my origin. Do I need to dial the connection so that it reaches it via VPN? We only have one Link that authenticates through a pppoe dialer.
Thanks.
The world is full of misunderstandings. As you say that incoming connections to servers on your side from servers at their side are possible, I assume that the “nothing in the logs” is not related to establishing the IPsec communication channel but to the requests delivered via that channel.
But to answer your questions, there is no need to dial anything, Mikrotik keeps trying to establish the IPsec Phase 1 all the time and Phase 2 in the beginning and then every time it needs to deliver a payload packet if the peer has torn down the Phase 2 in the meantime.
What do /ip ipsec active-peers print and /ip ipsec installed-sa print show?
What does /ip firewall nat print show?
[admin@MikroTik] > /ip ipsec active-peers print
Flags: R - responder, N - natt-peer
# ID STATE UPTIME PH2-TOTAL
0 R OHTER SIDE established 3d3h51m23s 1
1 RN OTHER SIDE established 3d3h51m17s 1
[admin@MikroTik] > /ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=0xE18BCA6 src-address=OTHER SIDE dst-address=MY SIDE
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
enc-key-size=256 auth-key="3c53521b9e11c1347bb206f970ebf34c76c93dae"
enc-key="84821bd750d461cbdb1c00354585104d4d35d22e6c520833ca1706e69d724bd
0"
add-lifetime=6h24m11s/8h14s replay=128
1 HE spi=0x38527A2F src-address=MY SIDE dst-address=OTHER SIDE
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
enc-key-size=256 auth-key="4edc5951230955710c5f7da8b5dc9f4506298926"
enc-key="9cb9cb430f8beba8406a56ade9bc348219539ffb13baea78ad53a809ec9d5b7
3"
add-lifetime=6h24m11s/8h14s replay=128
2 HE spi=0xEEE89CB src-address=OTHER SIDE:4500
dst-address=MY SIDE:4500 state=mature auth-algorithm=sha256
enc-algorithm=aes-cbc enc-key-size=256
auth-key="c9cacc2889abb7a3e2cb9150bfa044689383bd5b307a239bf11aa4140903ae
03"
enc-key="1815f76f192cfa0ffa87a5ec096d711368979bbc3e2ad91e50efa10d72d0226
5"
add-lifetime=48m6s/1h8s replay=128
3 HE spi=0xF7CE6C0D src-address=MY SIDE:4500
dst-address=OTHER SIDE:4500 state=mature auth-algorithm=sha256
enc-algorithm=aes-cbc enc-key-size=256
auth-key="55facba9bf8be632331a4578a865d66d3ad22e209305f3c9f1e421de8b71d8
88"
enc-key="fcbde8d0fb42ef6fe31f1b0d0905a2e3e9810197d0a79c72a2ea0cc62473e64
d"
add-lifetime=48m6s/1h8s replay=128
[admin@MikroTik] >
[admin@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; MASQUERADE
chain=srcnat action=masquerade log=no log-prefix=""
1 D chain=dstnat action=jump jump-target=hotspot hotspot=from-client
2 D chain=hotspot action=jump jump-target=pre-hotspot
3 D chain=hotspot action=redirect to-ports=64872 protocol=udp dst-port=53
4 D chain=hotspot action=redirect to-ports=64872 protocol=tcp dst-port=53
5 D chain=hotspot action=redirect to-ports=64873 protocol=tcp
hotspot=local-dst dst-port=80
6 D chain=hotspot action=redirect to-ports=64875 protocol=tcp
hotspot=local-dst dst-port=443
7 D chain=hotspot action=jump jump-target=hs-unauth protocol=tcp
hotspot=!auth
8 D chain=hotspot action=jump jump-target=hs-auth protocol=tcp hotspot=auth
9 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=80
10 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp
dst-port=3128
11 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp
dst-port=8080
12 D chain=hs-unauth action=jump jump-target=hs-smtp protocol=tcp dst-port=2>
13 D chain=hs-auth action=redirect to-ports=64874 protocol=tcp hotspot=http
14 D chain=hs-auth action=jump jump-target=hs-smtp protocol=tcp dst-port=25
15 X ;;; place hotspot rules here
chain=unused-hs-chain action=passthrough
16 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.5.50.0/24
Your action=masquerade in chain srcnat of table nat is not selective which probably causes additional issues. But for your purpose, place a rule chain=srcnat action=accept ipsec-policy=out,ipsec before (above) the action=masquerade one. I would also add out-interface=ether1 or out-interface-list=WAN depending on your actual configuration, and src-address-type=!local, to the action=masquerade rule, to limit its effect only to the traffic where it is actually needed. And since the tracked connections in the firewall survive for 3 minutes since seeing last packet from either side, which effectively means forever, you have to get rid of them after the changes. The easiest way is to reboot the router. If it is not possible, I will explain how to remove them selectively.
I applied the changes you requested and restarted the router
[admin@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=accept log=no log-prefix="" ipsec-policy=out,ipsec
1 ;;; MASQUERADE
chain=srcnat action=masquerade src-address-type=local
out-interface=pppoe-out1 log=no log-prefix=""
2 D chain=dstnat action=jump jump-target=hotspot hotspot=from-client
3 D chain=hotspot action=jump jump-target=pre-hotspot
4 D chain=hotspot action=redirect to-ports=64872 protocol=udp dst-port=53
5 D chain=hotspot action=redirect to-ports=64872 protocol=tcp dst-port=53
6 D chain=hotspot action=redirect to-ports=64873 protocol=tcp
hotspot=local-dst dst-port=80
7 D chain=hotspot action=redirect to-ports=64875 protocol=tcp
hotspot=local-dst dst-port=443
8 D chain=hotspot action=jump jump-target=hs-unauth protocol=tcp
hotspot=!auth
9 D chain=hotspot action=jump jump-target=hs-auth protocol=tcp hotspot=auth
10 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=80
11 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp
dst-port=3128
12 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp
dst-port=8080
13 D chain=hs-unauth action=jump jump-target=hs-smtp protocol=tcp dst-port=2>
14 D chain=hs-auth action=redirect to-ports=64874 protocol=tcp hotspot=http
15 D chain=hs-auth action=jump jump-target=hs-smtp protocol=tcp dst-port=25
16 X ;;; place hotspot rules here
chain=unused-hs-chain action=passthrough
17 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.5.50.0/24
It should have said src-address-type=**!**local - the exclamation mark is important (it is a logical “not”), and on the GUI (Winbox/Webfig), there is a rectangle like for a checkmark before the value; if you tick it, the exclamation mark appears there rather than the checkmark.
Done.
Great, and has it changed anything? I suppose you did reboot the router again after the change? So show me the output of /ip ipsec active-peers print and /ip ipsec installed-sa print again, once taken before you attempt to connect from your location to the remote one and once after such an attempt.
[admin@MikroTik] > ip ipsec active-peers print
Flags: R - responder, N - natt-peer
# ID STATE UPTIME PH2-TOTAL
0 R OTHER SIDE established 2h40m44s 1
1 RN OTHER SIDE established 2h40m38s 1
[admin@MikroTik] > /ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=0x1F9FF38 src-address=OTHER SIDE dst-address=MY SIDE
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="608de8a79140d8cff2d7729131827682dfde1422"
enc-key="431996c9140b8480da20ae46b43de1f56230025e9d8eae930e15e55a8dad289d"
add-lifetime=6h24m4s/8h6s replay=128
1 HE spi=0x3852FE74 src-address=MY SIDE dst-address=OTHER SIDE
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="ca2ec38799bedc50910c098a8e4a0395949fe9b7"
enc-key="8173124f5e2c35ce4737534f4eebab4aec4d3cbf18a0e0a1f1b3eb7d3534f6d4"
add-lifetime=6h24m4s/8h6s replay=128
2 HE spi=0x18EBD7A src-address=OTHER SIDE:4500 dst-address=MY SIDE:4500
state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256
auth-key="4f790228aab8a0e2977a71aa5f42f9452cf0f6265b6e5325dc5f2cee6f378110"
enc-key="6bfbb1ab30be8084131dcf2c6b57c605235c8d729a8d9162091bb1925be272dc"
add-lifetime=48m20s/1h25s replay=128
3 HE spi=0xF7CE6E6E src-address=MY SIDE:4500 dst-address=OTHER SIDE:4500
state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256
auth-key="f6eb61c08a6e764041fa999500f75f786cb28f6031b5f63206fdc9b35703baea"
enc-key="4e243acebdb0719fef5d04a0b93b3790ed651b473558a22c928df62472006b6f"
add-lifetime=48m20s/1h25s replay=128
I’ve asked for prints “before” and “after” an attempt to connect from a device at your end to a device at the Fortigate end, you have only posted one. So:
What it shows regardless the above is that there is still something strange, as you have two active peers with the same address (unless OTHER SIDE actually stands for two different addresses), one of them treated as a NATed one and the other one as a directly routed one (without any NAT on the path). So it looks as if the Fortigate itself has established one tunnel and some other device behind it has established another one.
There really are two VPNs, but with the same problem. I’ll wait until the company’s business hours are over to restore the settings and do everything from the beginning.
I restored the factory settings and added only what was necessary for DHCP assignment on the network and PPPOE authentication. But still, no traffic.
/ip ipsec active-peers print
Flags: R - responder, N - natt-peer
# ID STATE UPTIME PH2-TOTAL REMOTE-ADDRESS DYNAMIC-ADDRESS
0 RN REMOTE SIDE established 1h35m51s 1 REMOTE SIDE
[admin@MikroTik] > ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=0x271A9B1 src-address=REMOTE SIDE:4500 dst-address=MY SIDE:4500 state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256
auth-key="877f4a59bbd9b3197b6c35acdf598c1037463a3911ae572b2c37c4e665257cc1" enc-key="55f08414ffba130c6a10bcc56e2f1802068b9086654f989c443c22298757283c" add-lifetime=48m4s/1h6s replay=128
1 HE spi=0xF7CE740E src-address=MY SIDE:4500 dst-address=REMOTE SITE:4500 state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256
auth-key="fb9a19de7b8d158545e85ce3f9154048af9de9a4a8d182e705045bf459a8b6cd" enc-key="7549dd786069cdaba7be781d9f02345d391d1201cc929d8afeedd222b3737d38" add-lifetime=48m4s/1h6s replay=128
/ip ipsec policy
add dst-address=10.198.8.0/22 peer="VPN AWS" proposal="VPN AWS" src-address=172.16.0.0/29 tunnel=yes
/ip ipsec identity
add peer="VPN AWS" secret=xxxxxxxxxxxxxxxxxxx
/ip ipsec profile
add dh-group=modp4096 enc-algorithm=aes-256,3des hash-algorithm=sha256 name="VPN AWS"
/ip ipsec peer
add address=PUBLIC REMOTE IP/32 exchange-mode=ike2 name="VPN AWS" profile="VPN AWS"
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h name="VPN AWS" pfs-group=modp4096
/ip address
add address=192.168.0.1/24 interface=LOCAL network=192.168.0.0
/ip firewall filter
add action=accept chain=input comment="Permitir IPsec (IKE)" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="Permitir IPsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="Encaminhar ESP (IPsec)" protocol=ipsec-esp
add action=accept chain=forward comment="Permitir Local -> AWS" dst-address=10.198.8.0/22 src-address=192.168.0.0/24
add action=accept chain=forward comment="Permitir AWS -> Local" dst-address=192.168.0.0/24 src-address=10.198.8.0/22
add action=accept chain=input comment="Permitir trfego TCP entrada no PPPoE" in-interface=pppoe-out1 protocol=tcp
add action=accept chain=forward comment="Encaminhar trfego TCP no PPPoE" in-interface=pppoe-out1 protocol=tcp
/ip firewall nat
add action=accept chain=srcnat comment="Exceo NAT para VPN" dst-address=10.198.8.0/22 src-address=192.168.0.0/24
add action=masquerade chain=srcnat out-interface=pppoe-out1
/ip route
add distance=1 dst-address=10.198.8.0/22 gateway=pppoe-out1
add distance=1 dst-address=172.16.0.0/29 gateway=pppoe-out1
Unless you have obfuscated the actual subnets involved and made a mistake in that process, the NAT rule that should exempt traffic matching the policy from getting masqueraded is wrong as it matches on src-address=192.168.0.0/24 whereas the policy has src-address=172.16.0.0/29. Matching on ipsec-policy=out,ipsec instead, as I suggested, aviods that type of mistakes.
But maybe I have completely misunderstood your original question and you actually want 192.168.0.0/24 to talk directly with 10.198.8.0/22? If so, the policy must be set to dst-address=10.198.8.0/22 src-address=192.168.0.0/24. My original understanding was that 192.168.0.0/24 was the LAN subnet on one of your routers, acting as an IPsec peer of the Fortigate, and 172.16.0.0/29 was the subnet on some other router reachable via 192.168.0.x.
If there is actually just one router on your side and 172.16.0.0/29 is some kind of virtual subnet that the Fortigate side forces you to use for the IPsec connection although you actually use the 192.168.0.0/24, you do need NAT between the subnets, but since you cannot map a /24 subnet to a /29 one 1:1, you have to specify individual dst-nat rules.
But neither of those explains how the access from the Fortigate side to your on-prem subnet works as you stated before. So please clarify the topology, otherwise we won’t get anywhere.