Hey guys,

I'm currently having major issues setting up an IPSEC vpn to remote Fortigate router.

My setup
SXT Lite5 ac cpe running pppoe on wlan for internet
Lan is on ether1 with dhcp 192.168.0.0/24

IPSEC Configuration
SRC. Address 0.0.0.0/0
DST. Address 0.0.0.0/0
SA SRC. Address my-public-ip
SA DST. Address remote-public-ip

Protocol:ESP
Tunnel: ticked
Level: unique
Action: Encrypt

Firewall Nat
SRC. Address 192.168.0.0/24
Action SRC-NAT
To Addresses: my-public-ip

The tunnel will phase2 establish and I can ping remote webserver from CPE, but not from LAN PC

Below is remote VPN requirments for Fortigate;

Internet Key Exchange Configuration
Authentication Algorithm: SHA-512
Encryption Algorithm: AES-256-CBC
Lifetime (seconds): 86400
Phase 1 Negotiation Mode: MAIN
Perfect Forward Secrecy: Diffie-Hellman Group 20

IPsec Configuration
Protocol: ESP
Authentication Algorithm: SHA-512
Encryption Algorithm: AES-256-CBC
Lifetime (seconds): 3600
Mode: Route Based
Perfect Forward Secrecy: Diffie-Hellman Group 20

Diffie-Hellman Group 2 on mikrotik I have ecp384


Firewall rules;
/ip firewall filter
add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
add action=accept chain=input comment="allow l2tp" dst-port=1701 protocol=udp
add action=accept chain=input comment="allow pptp" dst-port=1723 protocol=tcp
add action=accept chain=input comment="allow sstp" dst-port=443 protocol=tcp
add chain=input comment="ipsec-ah" proto=ipsec-ah action=accept
add chain=input comment="ipsec-esp" proto=ipsec-esp action=accept


If anyone can help with the solution for this problem, I will reward them.

What does /ip firewall nat print say?

Hey Sindy,

/ip firewall nat print
0 ;;; Wan Src-Nat
chain=srcnat action=src-nat to-addresses=my-public-ip src-address=192.168.0.0/24 log=no log-prefix=""

Well, so all packets with source address from the LAN subnet will be src-nated to the public IP. Is that what you actually want, i.e. will the Fortinet machine route the response packets to that address via the IPsec tunnel?

The point is that the packets are matched by IPsec policy only after the src-nat rule is executed. Your IPsec policy does not care about src-address as you have set it to 0.0.0.0/0, so these packets will be sent towards the Fortinet, but the way back may be a problem.

The other (independent) issue is that your policy will also handle any packets coming back as also its dst-address is set to 0.0.0.0/0. So you should restrict the src-address of the policy to just 192.168.0.0/24 or just the public IP, in accord with the src-nat setting, depending on whether you want the Fortinet to see the actual LAN addresses or the public one.

If the Fortinet insists that you use 0.0.0.0/0 as both src-address and dst-address of the policy, you'll have to place an exception policy in front of the policy associated to the SA, which will prevent the latter from redirecting packets for devices on your LAN back to the tunnel:

Hi Sindy,

Thank you for your very helpful detailed reply, I added /ip ipsec policy add place-before=0 action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24 place-before=0
I can now open up webserver in browser with the IP of the webserver, but when I try to go to the actually webserver domain address, I get Server not found and webpage wont load.

IPSEC Gateway a.a.a.a
Webserver b.b.b.b
I was told that the traffic to web server should be routed out IPSEC Gateway

IPSEC Gateway a.a.a.a
Webserver b.b.b.b

I Added routes to /IP Routes
Dst. address a.a.a.a Gateway WAN
Dst. address b.b.b.b Gateway WAN

I can ping webserver and my PC on the Lan, but cant load up any website or the webserver domain, only the webserver IP I can reach from the web browser

Any help would be much obliged

What you are missing so far is that vanilla IPsec (which you use) works independent of the routing, or better to say it supersedes the routing after the routing has been done. Unlike other VPN types, IPsec doesn't create a tunnel interface which you could use as a gateway. So it only needs that the normal routing would send the packet somewhere, not to a blackhole. And then, after all routing and firewall operations including NAT have been done, IPsec policies inspect the packets and if they like them, they steal them, encrypt them and send them through their respective IPsec tunnels called security associations.

So in your case where the main IPsec policy says that everything (dst-address=0.0.0.0/0) shall be set via the tunnel, the specific route you have added for the web server, i.e. dst-address=b.b.b.b gateway=WAN, doesn't change anything about that behaviour.

And as you can open the web page on the server using the browser if you put there its IP address, but cannot open it if you put there its domain name, I would assume that the issue is with DNS operation. So you should first try to ping the server's domain name, and if it fails either, it is definitely a DNS issue. I would expect that your DNS servers are unreachable via the IPsec tunnel because

• they are somewhere else in your LAN than in 192.168.0.0/24, or
• because the Fortigate filters DNS requests to any servers except the ones they've told you, or
• because the DNS servers you've configured do not accept queries from the address to which the Fortigate NATs you (if it does).
• because the server name is only registered in the DNS of thr Fortigate and public DNSes don't know about its existence, and the Fortigate does not redirect DNS requests to its own servers

So all in all, describe better the situation to get a more targeted advice. I know silence is golden but not when you need support.

Hi Sindy,

I am able to ping the webserver domain name and it translated the domain to the IP address.
The dns server settings are auto giving to my via PPPoE on the mikrotik and I have remote requests on with the router IP 192.168.0.1 added to the dns list.
If I turn off PPPoE "Use Peer DNS" I can input my own, which I have done and tried google's DNS 8.8.8.8, 8.8.8.4.4
I also tried removing DNS servers from dhcp handouts on the router and adding DNS straight onto the NIC on my PC.
Once IPSEC is disabled, I can browse the internet like normal but when enabled I cannot.

The admin said that they don’t specify DNS as the webserver address can be resolved by any DNS server.
I can see traffic going over the tunnel when I ping the webserver.
The admin also said that everything looks okay from this end, he can see successful connections to the web server and data passing.
So that leaves the problem at my end

So to recap:

• With tunnel down, you can access web pages by name and ping the servers by name, except the server for which you needed the IPsec, yes/no?
• With tunnel up, you can access web pages and ping the servers by address, including the server for which you needed the IPsec, yes/no?
• With tunnel up:
  • can you ping servers in the internet by name (chose servers you haven't visited today so that DNS cache doesn't affect the results)?
  • can you ping that server of interest by name?

And also explain the uplink. You mention PPPoE on your own 'Tik and a router at 192.168.0.1, so you have two uplinks? Normally the ADSL routers either work as routers so you cannot run pppoe client on the 'Tik, or they work as bridges so you run the pppoe but in such case the DNS on the router cannot work as it cannot see the internet, forwarding the PPPoE to you.

So to recap:
With tunnel down, you can access web pages by name and ping the servers by name, except the server for which you needed the IPsec, yes
With tunnel up, you can access web pages and ping the servers by address, including the server for which you needed the IPsec, yes/no? no, I cannot access any websites only the IP of webserver is all.

With tunnel up:
can you ping servers in the internet by name (chose servers you haven't visited today so that DNS cache doesn't affect the results)? No
can you ping that server of interest by name? No, I can ping webserver by IP

I have a Mikrotik SXT CPE,
Wlan wireless station mode to ISP Sector AP
PPPoE runs on the Wlan and the ether1 is connect into my PC, DHCP runs on ether1 192.168.0.0/24
Wlan and ether1 are not bridged

Well, could it be that I am missing the key information that the tunnel is only there to access that particular server b.b.b.b, and it actually does not deliver to the destination any other traffic than that for the web server? Because the policy in your first post suggested that this VPN should take your complete internet traffic, but maybe it is the mistake which has only spawned a chain of misunderstanding?

I have an IP address that is for the VPN use only and not to browse the internet.
The IPSEC VPN is used to access the remote webserver login portal page securely, not to browse the internet under the VPN.
But when I use the IP of the webserver it will show that I can reach webserver and I can ping it also from PC and Tik device, but it wont show the login page.

It's not until I use your rule /ip ipsec policy add place-before=0 action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24 place-before=0
then I can reach the webserver via the IP address, when I disable above rule I cannot access the webserver via the IP, so that was a step in the right direction.

IPSEC Configuration
VPN Type Route Based
VPN selectors should be 0.0.0.0/0.0.0.0
It is recommend that the client environment is NATed to public IP addressing.

Well, the problem is that "VPN selectors 0.0.0.0/0-0.0.0.0/0", which is another name for what Mikrotik calls ipsec policy, mean to send everything through the tunnel. And while it was easy to cut away the local LAN from that, it will not be so easy to cut everything except the IP of the web server (b.b.b.b).

So first try to change the policy from src-address=0.0.0.0/0 dst-address=0.0.0.0/0 to src-address=0.0.0.0/0 dst-address=b.b.b.b/32; if the tunnel establishes, we're good, if it doesn't, it will require some complex action=none policies before this one.

IPSEC Gateway a.a.a.a
Webserver b.b.b.b

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active,
* - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=b.b.b.b
dst-port=any protocol=all action=none

1 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any
protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=My-Public-IP sa-dst-address=a.a.a.a
proposal=default ph2-count=1


The tunnel will establish but I cannot reach the webportal via domain or IP with the changes,

Thank you for your help Sindy

IPSEC Gateway a.a.a.a
Webserver b.b.b.b

What you've done is not what I had in mind.
The policy with action=none should have remained unchanged (i.e. with dst-address=192.168.0.0/24) for the moment.
The policy with action=encrypt should have dst-address=b.b.b.b instead of dst-address=0.0.0.0/0.

So the result should be this:

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active,
* - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24
dst-port=any protocol=all action=none

1 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=b.b.b.b/32 dst-port=any
protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=My-Public-IP sa-dst-address=a.a.a.a
proposal=default ph2-count=1

But as said - the peer may not accept the connection because it gets the information about the policy we use towards it, so if it only accepts connections with policy's dst-address=0.0.0.0/0, we have an issue which needs to be worked around. On the other hand, if the peer accepts it and it works, the policy with action=none will become redundant and it will be possible to remove it.

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active,
* - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24
dst-port=any protocol=all action=none

1 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=b.b.b.b/32 dst-port=any
protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=My-Public-IP sa-dst-address=a.a.a.a
proposal=default ph2-count=1


I adjusted configuration to above, the connection wont establish with the new changes. Is there any way to troubleshoot what is happening at my side so I can submit results here or is it all trial and error?

It is what I have anticipated. The Fortigate administrator expects that every device in the world behaves like his Fortigate, so he does not even dream that forcing people into use of a policy which matches on all traffic can cause trouble on the clients' side.
To work this around, you will need a pile of action=none policies which will match on packets which should not get to his network, so that only what will get through all those policies unmatched would finally hit that 0.0.0.0/0->0.0.0.0/0 policy and get to him. To make it simpler, I'll show you the method on the first two bytes of the IP address. I hope you are familiar with the conversions between binary and decimal notation and the IP mask construction principle.

So let's say the first two bytes of the b.b.b.b are 217.125. This, in binary, is 1101 1001 0111 1101‬. So we have to go bit by bit and create all the prefixes of different lengths from 1 to 32 which match this value in all their bits except the last one:

prefix table code

1101 1001   ‭0111 1101‬
---------------------
0... ....   .... .... => 0.0.0.0/1
10.. ....   .... .... => 128.0.0.0/2
111. ....   .... .... => 224.0.0.0/3
1100 ....   .... .... => 192.0.0.0/4
1101 0...   .... .... => 208.0.0.0/5
1101 11..   .... .... => 220.0.0.0/6
1101 101.   .... .... => 218.0.0.0/7
1101 1000   .... .... => 216.0.0.0/8
1101 1001   1... .... => 217.128.0.0/9 
1101 1001   00.. .... => 217.0.0.0/10
1101 1001   010. .... => 217.64.0.0/11
1101 1001   0110 .... => 217.96.0.0/12
1101 1001   0111 0... => 217.112.0.0/13
1101 1001   0111 10.. => 217.120.0.0/14
1101 1001   0111 111. => 217.126.0.0/15
1101 1001   0111 1100 => 217.124.0.0/16

So for the actual address b.b.b.b, you have to calculate all the 32 prefixes of non-matching subnet the way above, and use each of them as dst-address of an /ip ipsec policy action=none placed above the single policy with action=encrypt dst-address=0.0.0.0 required by the Fortigate. The good point is that if you go this way, you can remove the previously added policy with action=none as one of those will substitute it.

But there may be a much easier way which you should try first. The guy asks you to send him packets with a public address as a source one, and the reason is that he needs to be sure that two clients won't send him packets from the same address, so that the Fortigate knew where to route the responses. But it does not necessarily need to be the same public address from which you establish the tunnel.

So do the following - keep the configuration with just the two policies we had yesterday, action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24 and action=encrypt src-address=0.0.0.0/0 dst-address=0.0.0.0/0, and put above the action=encypt one yet another action=none one with src-address=your.wan.ip.address dst-address=0.0.0.0/0

This will make the tunnel establish successfully but will prevent anything from being sent through it, because whatever you send outside your LAN is first src-nated to your WAN public address.

Now take some public IP address which you control and are sure that it won't ever connect to that Fortigate's VPN, say, m.m.m.m, and add the following rule above the currrent action=masquerade or action=src-nat rule you use in /ip firewall nat chain=srcnat:

/ip firewall nat add chain=srcnat action=src-nat dst-address=b.b.b.b to-addresses=m.m.m.m

So the source address of packets you sent to b.b.b.b will be translated to m.m.m.m, so the second policy with action=none will ignore them, and the action=encrypt policy will match them and send them to the Fortigate.

IPSEC Gateway a.a.a.a
Webserver b.b.b.b

0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24
dst-port=any protocol=all action=none

1 ;;; VPN
src-address=My-Public-IP/32 src-port=any dst-address=0.0.0.0/0
dst-port=any protocol=all action=none

2 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any
protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=My-Public-IP sa-dst-address=a.a.a.a
proposal=default ph2-count=1


I added a second PPPoE with a new public IP, So there is two PPPoE running at the same time with two different public addresses, is this correct?

Firewall Rule
/ip firewall nat add chain=srcnat action=src-nat dst-address=b.b.b.b to-addresses=New-Public-IP

Results;
Tunnel will establish, but I cannot reach the webserver via domain address or IP address of webserver.

If I disable the second PPPoE and the added new firewall nat rule.
I am able to browse the internet like normal with the new policy rule active and the tunnel is established.

Thanks for your time with all this.

I don't know whether you have static addresses or dynamic on the PPPoE, but from your description it seems they are dynamic which makes the setup quite unstable (as soon as the addresses change, it will stop working until you adjust the rules to the addresses), something which the one with 32 exception policies is not sensitive about.

In any case, change the settings of the /interface pppoe-client in such a way that the one with your normal public address is allowed to add default gateway and the other one is not. So even if the second one is up, your packets will always go out via the first one. The public address of the first pppoe (which is allowed to become the default route's gateway iterface) must be the one in the policy with action=none, the public address of the second pppoe (which is not allowed to become the default route's gateway interface) must be in the rule I gave you. Just to check, please give me the output of /interface pppoe-client export hide-sensitive and /ip firewall nat export, replacing the IP addresses there of course.

Default Route
0.0.0.0/0 Gatway pppoe-out1

/interface pppoe-client
add disabled=no interface=wlan2 keepalive-timeout=60 name=pppoe-out1 use-peer-dns=yes user=*******1
add disabled=no interface=wlan2 name=pppoe-out2 user=*******2

/ip firewall nat
add action=src-nat chain=srcnat comment="Public-Ip-2 to Webserver IP" dst-address=b.b.b.b to-addresses=m.m.m.m
add action=src-nat chain=srcnat comment="Public-Ip-1 Src-Nat" src-address=192.168.0.0/24 to-addresses=z.z.z.z

Okay. And with this setup, you can get to the internet normally, the IPsec tunnel is up, but you cannot connect to the server b.b.b.b neither by IP nor by name? And when you try, you can see the /ip ipsec installed-sa from your z.z.z.z to their a.a.a.a to count packets and bytes but the one for the opposite direction doesn't?

z.z.z.z is Public IP 1
m.m.m.m is Public IP 2
b.b.b.b Webserver
a.a.a.a IPSEC Gateway


No default route for Public IP 2
Default route for Public IP 1 is 0.0.0.0/0 gateway pppoe-out1

/ip ipsec installed-sa from your z.z.z.z to their a.a.a.a to count packets and bytes but the one for the opposite direction doesn't? That is correct, it's one direction only

Strange thing is that with the policy rule
/ip ipsec policy add place-before=0 action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24 place-before=0

The web portal page via the domain with the default route disabled did load up but it was hit and miss on loading and needed to be refreshed a few times to get it to load.
Then it just stopped working for no reason and now it has never work again.

This may not be my problem but the admin states that everything is fine at there end.

In one of the initial posts you have posted your firewall rules, is that the complete /ip firewall filter print? Because there were no rules with chain=forward which is unusual, and if there is a rule in forward chain which says action=fasttrack-connection, you have to disable it or take special measures that it wouldn't prevent IPsec from working.

0 ;;; allow l2tp
chain=input action=accept protocol=udp dst-port=1701 log=no log-prefix=""

1 ;;; allow pptp
chain=input action=accept protocol=tcp dst-port=1723 log=no log-prefix=""

2 ;;; allow sstp
chain=input action=accept protocol=tcp dst-port=443 log=no log-prefix=""

3 ;;; ipsec-ah
chain=input action=accept protocol=ipsec-ah log=no log-prefix=""

4 ;;; allow IKE
chain=input action=accept protocol=udp dst-port=500,4500 log=no
log-prefix=""

5 ;;; ipsec-esp
chain=input action=accept protocol=ipsec-esp log=no log-prefix=""

6 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp log=no log-prefix=""

7 ;;; Allow WinBox
chain=input action=accept protocol=tcp dst-port=8291 log=no log-prefix=""

8 ;;; defconf: accept established,related
chain=input action=accept connection-state=established,related log=no log-prefix=""

9 ;;; defconf: accept established,related
chain=forward action=accept connection-state=established,related log=no log-prefix=""

10 ;;; Allow DNS for trusted network
chain=input action=accept protocol=udp src-address=192.168.0.0/24 dst-port=53 log=no log-prefix=""

11 ;;; Allow DNS for trusted network
chain=input action=accept protocol=tcp src-address=192.168.0.0/24 dst-port=53 log=no log-prefix=""

12 ;;; Allow local network
chain=input action=accept src-address=192.168.0.0/24 log=no log-prefix=""

13 ;;; defconf: drop all from WAN
chain=input action=drop in-interface=pppoe-out1 log=yes log-prefix=""

14 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=yes log-prefix=""

15 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=pppoe-out1 log=no log-prefix=""

16 chain=input action=drop connection-state=new protocol=udp in-interface=pppoe-out1 dst-port=53 log=no log-prefix=""

17 chain=input action=drop connection-state=new protocol=tcp in-interface=pppoe-out1 dst-port=53 log=no log-prefix=""

Okay. As there is no fasttracking rule, that is not the explanation. So two explanations remain - either something is really broken at the Fortigate side, or the Foritgate insists that the address from which the tunnel packets are coming must the same like the one of the payload, which this setup breaks because the transport packets come from z.z.z.z and the payload ones unpacked from there come from m.m.m.m.

If the second is true, you have to calculate those 32 subnet prefixes. Are you able to do that or was that table and procedure totally incomprehensible to you?

There might still be a possibility not to do it but it would require that you had the two public addresses active, do you want that one instead?

I could try the two public addresses active route first and if that fails, I will try the calculate 32 subnet prefixes solution. if all fails then it's at there end

OK. With the two public addresses, it requires a bit of policy routing, but not too much. What we need is that all normal traffic goes via pppoe-out1, so it remains the default gateway in the default routing table, and only the traffic to and via the Fortigate uses the other one. So you would do the following:

/ip route
add dst-address=0.0.0.0/0 gateway=pppoe-out2 routing-mark=via-wan-2

/ip route rule
add action=lookup-only-in-table table=via-wan-2 dst-address=a.a.a.a/32
add action=lookup-only-in-table table=via-wan-2 dst-address=b.b.b.b/32

All the remaining configuration remains in place (two policies with action=none, followed by one policy with action=encrypt).

z.z.z.z is Public IP 1
m.m.m.m is Public IP 2
b.b.b.b Webserver
a.a.a.a IPSEC Gateway[/b]


/ip route rule print
0 dst-address=a.a.a.a/32 action=lookup-only-in-table table=via-wan-2
1 dst-address=b.b.b.b/32 action=lookup-only-in-table table=via-wan-2


/ip firewall nat print
0 ;;; Wan Src-Nat Public IP 1 to Webserver
chain=srcnat action=src-nat to-addresses=z.z.z.z dst-address=b.b.b.b log=no log-prefix=""

1 ;;; Wan Src-Nat Lan to Public IP 1
chain=srcnat action=src-nat to-addresses=z.z.z.z src-address=192.168.0.0/24 log=no log-prefix=""


/ip ipsec policy
add action=none comment="VPN LAN" dst-address=192.168.0.0/24 src-address=0.0.0.0/0
add action=none comment="VPN Public IP 1" dst-address=0.0.0.0/0 src-address=z.z.z.z/32
add comment="VPN Public IP 1 to IPSEC Gateway" dst-address=0.0.0.0/0 sa-dst-address=a.a.a.a sa-src-address=z.z.z.z src-address=0.0.0.0/0 tunnel=yes

OK, disable both the existing NAT rules (don't delete them, just disable them) and add the following two in any order:

chain=srcnat action=masquerade out-interface=pppoe-out1
chain=srcnat action=masquerade out-interface=pppoe-out2

(and answer my several posts older question whether you get static or dynamic source addresses )

The ip addresses are both static IP's

What confuses me is that several posts back you had the nat rules set properly, one with to-addresses=m.m.m.m and the other one with z.z.z.z, and now with the policy routing, you were translating the packets to b.b.b.b also to source address z.z.z.z. The other part was my mistake, I haven't remembered that you don't use masquerade on the primary wan.

However, what's the outcome after replacing those two NAT rules with the last ones?

z.z.z.z is Public IP 1
m.m.m.m is Public IP 2
b.b.b.b Webserver
a.a.a.a IPSEC Gateway

The nat rule was set to translate the 192.168.0.0/24 to Public IP 1 , which is static ip.
add action=src-nat chain=srcnat comment="Public-Ip-1 Src-Nat" src-address=192.168.0.0/24 to-addresses=z.z.z.z

The outcome is more the same result, the Vpn wont establish

I'm not sure why that policy was in there, should it be removed?
Translating the packets to b.b.b.b also to source address z.z.z.z.

Show me your current
/ip route print detail
/ip route rule print
/ip firewall nat print
/ip ipsec policy print

/ip route print detail
/ip route rule print
/ip firewall nat print
/ip ipsec policy print


/ip route print detail
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
0 A S dst-address=0.0.0.0/0 gateway=pppoe-out2 gateway-status=pppoe-out2 reachable distance=1 scope=30 target-scope=10
routing-mark=via-wan-2

1 A S dst-address=0.0.0.0/0 gateway=pppoe-out1 gateway-status=pppoe-out1 reachable distance=1 scope=30 target-scope=10

2 ADC dst-address=ISP-ROUTER-IP/32 pref-src=m.m.m.m-Public-IP-2 gateway=pppoe-out2,pppoe-out1
gateway-status=pppoe-out2 reachable,pppoe-out1 reachable distance=0 scope=10

3 X S dst-address=a.a.a.a-IPSEC-Gateway/32 gateway=pppoe-out1 gateway-status=pppoe-out1 inactive distance=1 scope=30
target-scope=10

4 X S dst-address=b.b.b.b-Webserver/32 gateway=pppoe-out1 gateway-status=pppoe-out1 inactive distance=1 scope=30
target-scope=10

5 ADC dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=ether1 gateway-status=ether1 reachable distance=0
scope=10


/ip route rule print
Flags: X - disabled, I - inactive
0 dst-address=a.a.a.a-IPSEC-Gateway/32 action=lookup-only-in-table table=via-wan-2

1 dst-address=b.b.b.b-Webserver/32 action=lookup-only-in-table table=via-wan-2


/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface=pppoe-out1

1 chain=srcnat action=masquerade out-interface=pppoe-out2



/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24 dst-port=any protocol=all action=none

1 ;;; VPN
src-address=z.z.z.z-Public-IP-1/32 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=none

2 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=z.z.z.z-Public-IP-1/32 sa-dst-address=a.a.a.a-IPSEC-Gateway/32 proposal=default
ph2-count=1

OMG, I forgot to tell you that in this setup the sa-src-address of the policy with action=encrypt must be set to m.m.m.m (of pppoe-out2).

The rest seems OK to me.

This is the last one from me today, too late here.

Still no joy with that change, thanks for your help today Sindy.

I get "no phase 2" but the admin requested my static IP for his end to create the VPN, the m.m.m.m (of pppoe-out2) is showing up in the "Installed SAs"
this couldn't be right as it would have to be the Public IP 1 for that what the admin has at his end for the tunnel.

Have a good night it was a long day

the admin requested my static IP for his end to create the VPN

This is an important bit of information which I haven't noticed in what you wrote so far
So everything remains as-is except that the roles of pppoe-out1 and pppoe-out2 have to be swapped in the scheme.
To do that, you have to

• return the sa-src-address in the action=encrypt policy to z.z.z.z
• set pppoe-out2 (m.m.m.m) to provide the default route and the pppoe-out1 (z.z.z.z) not to provide it
• change the gateway of the route with routing-mark=via-wan-2 to pppoe-out1

Good morning Sindy

Below are the results;

z.z.z.z is Public IP 1
m.m.m.m is Public IP 2
b.b.b.b Webserver
a.a.a.a IPSEC Gateway

0.0.0.0/0 pppoe-out1 Gateway Distance 2
0.0.0.0/0 pppoe-out2 Gateway Distance 1

Route to both are disabled in IP routes
b.b.b.b Webserver
a.a.a.a IPSEC Gateway

Once Pref. Source is pppoe-out2 IP address to the ISP router, the VPN connection will establish, sometimes the pppoe-out2 drops and the preferred sources switches in the routes to pppoe-out1 IP address becomes the Pref. Source
I increased the keepalive timeout in both pppoe client dial out.

I added google dns 8.8.8.8 to dns settings and turned on remote requests with the router ip 192.168.0.1 added to the list and also to the static dns.

I can ping the webserver with the Tik device and ping my PC from CMD on the PC
I can reach the webserver via the IP but not using the domain name.


/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24 dst-port=any protocol=all action=none

1 ;;; VPN
src-address=z.z.z.z-Public-IP-1/32 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=none

2 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=z.z.z.z-Public-IP-1/32 sa-dst-address=a.a.a.a-IPSEC-Gateway/32 proposal=default
ph2-count=1

With Policy 1 VPN enabled, I cannot ping or reach the webserver IP until I disable it

1 ;;; VPN
src-address=z.z.z.z-Public-IP-1/32 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=none

Policy 1 must have src-address=m.m.m.m now, not z.z.z.z.

The whole idea is: everything goes out via pppoe-out2 using m.m.m.m as source public address, with only two exceptions: the IPsec tunnel itself which must establish via pppoe-out1 using z.z.z.z as source public address, and the connection to the web server which must also be routed out using pppoe-out1 and using z.z.z.z as source public address.

Hence only pppoe-out2 must be allowed to add the default route (and no other default route without a routing-mark value must be present), and only pppoe-out1 must be set as a default route with routing-mark=via-wan-2 which the two items in /ip route rule force the two exceptional destinations to use. This last part can actually be further simplified but step by step, please.

Now the two action=none policies must steal all packets which the action=encrypt policy must not get hold of; these are the packets for your LAN (src-address=0.0.0.0/0 dst-address=192.168.0.0/24) and the packets sent out via pppoe-out2 (src-address=m.m.m.m/32 dst-address=0.0.0.0/0). So by setting the second policy's src-address to z.z.z.z you have blocked everything, both the normal internet access via pppoe-out2 and the access to the server via the tunnel via pppoe-1 using its z.z.z.z as source.

z.z.z.z is Public IP 1
m.m.m.m is Public IP 2
b.b.b.b Webserver
a.a.a.a IPSEC Gateway

Results of
/ip route print detail
/ip route rule print
/ip firewall nat print
/ip ipsec policy print


/ip route print detail
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
0 A S dst-address=a.a.a.a-IPSEC-Gateway/32 gateway=pppoe-out1 gateway-status=pppoe-out1 reachable distance=1 scope=30
target-scope=10 routing-mark=via-wan-2

1 A S dst-address=b.b.b.b-Webserver/32 gateway=pppoe-out1 gateway-status=pppoe-out1 reachable distance=1 scope=30
target-scope=10 routing-mark=via-wan-2

2 A S dst-address=0.0.0.0/0 gateway=pppoe-out2 gateway-status=pppoe-out2 reachable distance=1 scope=30 target-scope=10

3 ADC dst-address=ISP-Router pref-src=m.m.m.m-Public-IP-2/32 gateway=pppoe-out2,pppoe-out1
gateway-status=pppoe-out2 reachable,pppoe-out1 reachable distance=0 scope=10

4 ADC dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=ether1 gateway-status=ether1 reachable distance=0
scope=10


/ip route rule print
Flags: X - disabled, I - inactive
0 dst-address=a.a.a.a-IPSEC-Gateway/32 action=lookup-only-in-table table=via-wan-2

1 dst-address=b.b.b.b-Webserver/32 action=lookup-only-in-table table=via-wan-2


/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24 dst-port=any protocol=all action=none

1 ;;; VPN
src-address=m.m.m.m-Public-IP-2/32 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=none

2 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=z.z.z.z-Public-IP-1/32 sa-dst-address=a.a.a.a-IPSEC-Gateway/32 proposal=default
ph2-count=1


/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic

1 chain=srcnat action=masquerade out-interface=pppoe-out1

2 chain=srcnat action=masquerade out-interface=pppoe-out2



Connection to IPSEC VPN will establish and I can ping the webserver via IP but still cannot reach it via domain name using web browser.
I clear cache each time "ctrl F5" on each visit.

In the IPsec Peer, Address is the a.a.a.a IPSEC Gateway
Local Address is z.z.z.z is Public IP 1

Now I cannot see any mistake.

When you disable the peer and the tunnel is down, do the following on the Mikrotik's command line:
/ip dns cache flush
/put [resolve cloud.mikrotik.com]
/put [resolve the-name-of-b.b.b.b-server]

Then enable the peer, wait until the tunnel is up, and repeat the same steps above.
Do you get the same results in both cases? If you don't, post the output in both cases.

Ok Sindy,

When Peer is disabled and I run the three commands I get "failure: dns server failure" on both
/put [resolve cloud.mikrotik.com]
/put [resolve the-name-of-b.b.b.b-server]

Same results when the Peer is enabled and tunnel is established

/ip dns print

/ip dns print
servers: 8.8.8.8,8.8.4.4
dynamic-servers:
allow-remote-requests: yes
max-udp-packet-size: 4096
query-server-timeout: 2s
query-total-timeout: 10s
max-concurrent-queries: 100
max-concurrent-tcp-sessions: 20
cache-size: 2048KiB
cache-max-ttl: 1w
cache-used: 22KiB

/ip settings print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: strict
tcp-syncookies: yes
max-neighbor-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 15
icmp-rate-mask: 0x1818
route-cache: yes
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: no
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

That sounds like a RouterOS bug to me. What version do you run? Normally, the policies are evaluated in order and the action=encrypt ones are only active when the corresponding security association exists.

Disable not only the peer but also the policy with action=encrypt and try the dns flush and two resolves again.

Mikrotik version 6.42.6 (stable)

When I enable the pppoe-out1 and run command
/put [resolve cloud.mikrotik.com]
failure: dns name does not exist

When I disable the pppoe-out1, VPN IPSEC PEER and all Policies
/put [resolve cloud.mikrotik.com]
81.198.87.240
/put [resolve webserver.domain.com]
b.b.b.b Webserver IP

When I visit the webserver domain I can see it resolving in the DNS cache on the Tik device when VPN is disabled and pppoe-out1 is disabled.

Okay. So try to enable everything, but place two more policies to the beginning of the policy list:

src-address=0.0.0.0/0 dst-address=8.8.8.8/32 action=none
src-address=0.0.0.0/0 dst-address=8.8.4.4/32 action=none

and try the dns flush and resolve again.

I suspect that the policy ordering may have a problem with the src-address.

That's done but still same results with command

/put [resolve the-name-of-b.b.b.b-server]
failure: dns server failure

Id say all solution's must be exhausted by now

Me too, but it makes no sense to me.

Disable pppoe-out2, the ip route rules and the policy with src-address=m.m.m.m and try again the dns steps.

Sindy,

I disabled all configuration to do with pppoe-out2.

Current Setup

IP Route
0.0.0.0/0 pppoe-out1 Gateway Distance 1

Gateway pppoe-out1 for below Rules
dst-address=a.a.a.a-IPSEC-Gateway/32 action=lookup-only-in-table table=via-wan-2
dst-address=b.b.b.b-Webserver/32 action=lookup-only-in-table table=via-wan-2


Active Policy Rules along with
src-address=0.0.0.0/0 dst-address=8.8.8.8/32 action=none
src-address=0.0.0.0/0 dst-address=8.8.4.4/32 action=none
src-address=0.0.0.0/0 dst-address=192.168.0.1/32 action=none


/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24 dst-port=any protocol=all action=none

2 A ;;; VPN
src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=z.z.z.z-Public-IP-1/32 sa-dst-address=a.a.a.a-IPSEC-Gateway/32 proposal=default
ph2-count=1


Now I have access to the webserver, via the domain name.

Thank you for your assistance, patience and your perseverance in helping to resolve this issue.

I would like to reward you for your assistance, how do I go about this?

Depends on the country/continent

Other than that, what surprises me most is that you don't care about internet access while you can get to the server b.b.b.b.

I supposed im just happy to have it working, would it take much extra configuration to have internet aswel?

You may try the following: copy the following code block including the last empty line, paste it to a text editor, replace the b.b.b.b by the actual IP address of the web server, and copy-paste the result to the terminal window on Mikrotik.
Doing so will add all the 32 policies with action=none, handling anything but the packets for b.b.b.b.