IPSec tunnel no phase2

techclerk · Tue Oct 27, 2020 7:52 pm

Hello,
I have some questions about IPSec tunnel, that I need to make work.
I have created IP sec tunnel
src = 10.20.10.20
dst= 150.100.100.105
My local net is 192.168.10.10/22
I have accept srcnat 150.100.100.100/16 rule in IP-NAT
I also have forward rule in IP-Filter rules
accept forward 150.100.100.100/16 to 192.168.10.10/22
accept forward 192.168.10.10/22 to 150.100.100.100/16
The tunnel says no phase2, but the status is established. No SA-s installed.
Also, I have route via ether1/wan/ to 150.100.100.100/16
Seems like there is something wrong with the tunnel, but the remote side can access 2 machines, which it needs to access
If the IPSec reports no phase 2, does this mean that I accept traffic directly via WAN without passing thru the IPSec, which is highly unsecure?
And why it says no phase2. I have other IPSec tunnel that works and exchanges keys, encrypts traffic and etc?
Or no phase2 means that there is tunnel and if I disable it the remote side will be unable to connect to the 2 machines...So there is tunnel, but no encryption?

sindy · Wed Oct 28, 2020 5:01 pm

The tunnel says no phase2, but the status is established. No SA-s installed.

This is actually the same information. The phase 2 count is exactly the count of SA pairs.

Seems like there is something wrong with the tunnel, but the remote side can access 2 machines, which it needs to access
If the IPSec reports no phase 2, does this mean that I accept traffic directly via WAN without passing thru the IPSec, which is highly unsecure?

Unless the policies are created dynamically, traffic which matches a policy should not be sent directly even if the policy has no active SA associated to it. So I'd rather expect the traffic to use some other SAs, which could also be the reason why the policy for this peer cannot establish its own SA - the policy may be shadowed by some previous one, /ip ipsec policy print should show that).

And why it says no phase2. I have other IPSec tunnel that works and exchanges keys, encrypts traffic and etc?

The phase 2 count is per peer.

Or no phase2 means that there is tunnel and if I disable it the remote side will be unable to connect to the 2 machines...So there is tunnel, but no encryption?

There is no "tunnel" without an SA. So as written above - either the traffic matches some other policy and uses it, or the policy for this traffic has some problem not related to shadowing by another one, and then the traffic may bypass IPsec completely.

techclerk · Wed Oct 28, 2020 6:45 pm

There is no "tunnel" without an SA. So as written above - either the traffic matches some other policy and uses it, or the policy for this traffic has some problem not related to shadowing by another one, and then the traffic may bypass IPsec completely.

I have other IPSec policy, but with completely different IP-s, subnets and peers.
Is there a way in the config above for the traffic to bypass IPSec? This is what I need to know.
There is no way for this traffic to use other policy.
The config is

src=10.20.10.20
dst = 150.100.100.105
the policy connects 2 subnets
150.100.100.100/16 and my local net - 192.168.10.10/22

The only rules I have are
accept scrnat 150.100.100.100/16
and
accept forward 150.100.100.100/16 to 192.168.10.10/22
accept forward 192.168.10.10/22 to 150.100.100.100/16

With these rules is there a way for the traffic to bypass IPSec?
The only other thing that I have is a route for
150.100.100.100/16 via Ether1.
I fail to understand how there is no phase2, but they have access to my local network.
If IPSec policy intercepts the traffic and I have configured it correctly, they should not be able to access my local network.

Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 T * ::/0 ::/0 all
1 A Policy1 yes 192.168.10.10/22 192.168.50.0/24 all encrypt require 4
2 Policy2 yes 192.168.10.10/22 150.100.100.100/16 all encrypt require 0

sindy · Wed Oct 28, 2020 7:12 pm

The firewall rules don't care which way a packet came in (directly via an interface or encrypted using IPsec via the same interface) unless you explicitly add ipsec-policy=in|out,ipsec|none to them. And if the connection is initiated from your side and you use more or less the default stateful firewall, you'd have to add a rule saying action=drop src-address=150.100.0.0/16 dst-address=192.168.8.0/22 ipsec-policy=in,none before the "accept connected, established" one to drop packets not coming in via an SA while they should.

So is the policy which doesn't come up configured statically or should it be dynamically created from a template once the IPsec "session" comes up?

Also, if you haven't properly excluded packets from 192.168.8.0/22 to 150.100.0.0/16 from src-nat or masquerade in /ip firewall nat, they may get src-nated to the WAN IP of your router and thus evade the policy even if it is statically configured - policy matching on outbound packets is done as the very last step, after all the firewall handling including the NAT one.

The usual solution to this, which is however normally necessary only with dynamically generated policies, is that you set up a route with a bridge interface with no member ports or with an unreachable IP address as a gateway.

So I'd first check the NAT. You can use /ip ipsec connection print detail where src-address~"192.168.10.10" dst-address~"150.100.100.100" while the connection is established; if it shows s in the leftmost column, you forgot to exclude it from NAT.

techclerk · Wed Oct 28, 2020 7:23 pm

So is the policy which doesn't come up configured statically or should it be dynamically created from a template once the IPsec "session" comes up?

It's static policy. Not created from template.
I have accept srcnat 150.100.100.100/16 before masquerade.
NAT traversal=disabled.
About the command - How exactly should I input it?
I'm new to IPSec. Usually, I use the Mikrotik for content filtering, 2 DCHP servers, one of which is on other port and isolated.
So, pretend that you are speaking to an idiot.

sindy · Wed Oct 28, 2020 7:39 pm

In that case, I need to see the complete config export. Please obfuscate the addresses more carefully than you did until now (192.168.10.10/22 is a way to set up an IP address on an interface but not a way to specify an address prefix to a firewall rule or policy) so that the dependencies between the addresses and prefixes don't get corrupt.

techclerk · Wed Oct 28, 2020 7:41 pm

In that case, I need to see the complete config export.

What do you need me to export?

sindy · Wed Oct 28, 2020 7:47 pm

About the command - How exactly should I input it?

Press the [Terminal] button in Winbox or WebFig and paste the command to the commandline window that opens.

sindy · Wed Oct 28, 2020 7:50 pm

What do you need me to export?

Open the terminal window as said in the previous post. Then, type /export hide-sensitive file=somename and press enter. Next, download the file somename.rsc, and proceed to the obfuscation steps as given in my automatic signature right below before posting it here (between [code] and [/code] tags or as an attachment).

techclerk · Wed Oct 28, 2020 8:02 pm

....

/interface bridge
add admin-mac=********* auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] comment="WAN "
set [ find default-name=ether2 ] comment=LAN
set [ find default-name=ether10 ] poe-out=off
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip firewall layer7-protocol
add name="Youtube block" regexp="^.+(youtube.com).*\$"
/ip ipsec peer
add address=******8 local-address=20.20.20.20 name=P1
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 enc-algorithm=aes-128 name=\
    P1 nat-traversal=no
add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 name=P2 \
    nat-traversal=no
/ip ipsec peer
add address=150.100.100.105/32 local-address=20.20.20.20 name=P2 profile=\
    P2
/ip ipsec proposal
add enc-algorithms=aes-128-cbc name=secure
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm \
    lifetime=1h name="P1 Proposal" pfs-group=none
/ip pool
add name=DHCP ranges= ******
add name="DHCP Isolated" ranges=**********8
/ip dhcp-server
add add-arp=yes address-pool=DHCP disabled=no interface=bridge name="ALL INT"
add add-arp=yes address-pool="DHCP Isolated" disabled=no interface=ether5 \
    name="DHCP isolated"
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge interface=ether9
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=********** interface=bridge network=********
add address=*********** interface=ether5 network=*********
add address=******** interface=ether1 network=**********
/ip dhcp-server network
add address=********** comment="DHCP normal" dns-server=8.8.8.8 \
    gateway=*********8 netmask=22
add address=********* gateway=*******8 netmask=24
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall address-list
list=blocklist
list=allowedusers
/ip firewall filter
add action=drop chain=input comment="BlockWAN DNS req" dst-port=53 \
    in-interface-list=WAN protocol=udp
add action=drop chain=forward comment=SiteRestrictionRuleYoutubeQUC disabled=\
    yes dst-port=80,443 layer7-protocol="Youtube block" protocol=tcp \
    src-address-list=!allowedusers
add action=drop chain=forward comment=SiteRestriction dst-address-list=\
    blocklist src-address-list=!allowedusers
add action=accept chain=forward comment="P1" dst-address=\
    *********
add action=accept chain=forward comment="P1" protocol=tcp \
    src-address=*************
add action=accept chain=forward comment="P2" dst-address=\
    192.168.10.0/22 src-address=150.100.0.0/16
add action=accept chain=forward dst-address=150.100.0.0/16 src-address=\
    192.168.10.0/22
add action=drop chain=forward comment="Insulation ether5" dst-address=\
    ********* src-address=********88
add action=drop chain=forward dst-address=******** src-address=\
    *********8
add action=drop chain=forward comment="drop all from WAN not DSTNATed" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input comment=" drop invalid" connection-state=invalid
add action=accept chain=input comment="accept established,related,untracked" \
    connection-state=established,related,untracked
add action=accept chain=forward comment=\
    "accept established,related, untracked" connection-state=\
    established,related,untracked
add action=accept chain=forward comment="accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment=" accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    disabled=yes in-interface-list=!LAN
add action=drop chain=input comment="WAN intrusion protection" dst-port=8291 \
    in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=8291 protocol=udp
add action=drop chain=input dst-port=128 protocol=tcp
add action=drop chain=input dst-port=128 protocol=udp
add action=drop chain=input dst-port=129 protocol=tcp
add action=drop chain=input dst-port=129 protocol=udp
/ip firewall nat
add action=accept chain=srcnat src-address=********
add action=accept chain=srcnat src-address=150.10.0.0/16
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec identity
add peer=P1 secret="*********"
add peer=P2 secret=*************
/ip ipsec policy
add dst-address=******** peer=P1 proposal=secure sa-dst-address=\
    *********8 sa-src-address=*********8 src-address=******8 \
    tunnel=yes
add dst-address=150.100.0.0/16 peer=P2 proposal="P2 Proposal" sa-dst-address=\
    150.100.100.105 sa-src-address=20.20.20.20 src-address=192.168.10.0/22 \
    tunnel=yes
/ip route
add check-gateway=ping distance=1 gateway=********8
add distance=1 dst-address=********** gateway=ether1 pref-src=\
    ***********
add distance=1 dst-address=150.100.0.0/16 gateway=ether1 pref-src=\
    ***********

p.s I am familiar with simple commands like print and export. Not that kind of idiot. :)))

sindy · Wed Oct 28, 2020 8:32 pm

The action=accept rule in chain=srcnat should actually read action=accept src-address=192.168.8.0/22 dst-address=150.100.0.0/16. You've got the 150.100.0.0/16 as src-address there, which is wrong.

If ether1 is your WAN interface (you clearly did not understand what I wrote about obfuscating carefully in order not to obfuscate the relationship between the configured objects), setting it as a gateway of the routes used to prevent traffic intended to be encrypted using IPsec from leaking if something goes wrong may not work as intended. Under circumstances, the routing may find the gateway even if just an interface is specified.

techclerk · Wed Oct 28, 2020 9:13 pm

The action=accept rule in chain=srcnat should actually read action=accept src-address=192.168.8.0/22 dst-address=150.100.0.0/16. You've got the 150.100.0.0/16 as src-address there, which is wrong.

Why is wrong to accept the traffic from 150.100.0.0/16 in both ways? With the rule I intended to allow the pass thru between my local and remote subnets.
If the IPSec is operational, the traffic from their 150.100.0.0/16 subnet will be sent via the IPSec to my local subnet
And yes, ether1 is wan. WAN is just acronym in my Interface list. I have route from my WAN IP to the next device - router/media converter from the ISP.
The routes are - route to next device via ether1/WAN/ from proffered source - my wan IP.
Is there something in these rules that would allow the traffic to pass thru WAN/Ether1/ bypassing IPSec?
The whole scenario is - I have to establish bidirectional connection to their remote router, which is Cisco. I was given a certain config to enter in my Mikrotik.
I am connecting to a single device, but they have a group of devices behind the vpn, which all need to be able to access my net.

sindy · Wed Oct 28, 2020 9:21 pm

The rules in srcnat and dstnat chains only act on the very first packet of each connection. The rest of the connection's packets is then NATed or not depending on the handling activated by the first packet. So unless the connections are initiated from the remote side (150.100.0.0/16), the existing action=accept rule referring tro 150.100.0.0/16 as source is not harmful but does nothing. What you need is a rule that prevents connections initiated from your side (192.168.8.0/22) to the 150.100.0.0/16 from being src-nated by the masquerade rule. And I haven't seen such rule in the export.

Without that missing rule, the packets from 192.168.8.0/22 to 150.100.0.0/16 get src-nated to the WAN IP of ether1, and thus the policy ignores them.

techclerk · Wed Oct 28, 2020 9:32 pm

Without that missing rule, the packets from 192.168.8.0/22 to 150.100.0.0/16 get src-nated to the WAN IP of ether1, and thus the policy ignores them.

What kind of rule I need? And they try to connect and access resources. So then, isn't it true that they initiate connection to me?

sindy · Wed Oct 28, 2020 9:48 pm

Do they actually connect or they try to connect? Because if they can really connect to a resource on a private IP inside your LAN, there must be some tunnel somewhere - possibly on the external equipment (between Mikrotik's ether1 and the internet). If they sent a packet towards 192.168.8.0/22 via internet, it would not reach the Tik.

You need the rule I gave in the previous post, accepting packets from 192.168.8.0/22 to 150.100.0.0/16 before they can reach the masquerade rule, only if clients in your LAN initiate connections to the remote subnet.

techclerk · Wed Oct 28, 2020 9:58 pm

Because if they can really connect to a resource on a private IP inside your LAN, there must be some tunnel somewhere - possibly on the external equipment (between Mikrotik's ether1 and the internet). If they sent a packet towards 192.168.8.0/22 via internet, it would not reach the Tik.

They say that they can connect to 2 machines in my net from their net. On my side I have only Mikrotik and the ISP-s media converter. I can assure you that there is no vpn on my side somewhere else.
I fail to understand how I have traffic from 150.100.0.0/16 to 192.168.8.0/22, which I see in the matching firewall rule.
And this is while the IPSec says "no phase2" I know that Private network traffic should not and is not routable to internet. And my network is in private range - 192.168.x.x
So, before masquerade I need a rule that says
accept srcnat 192.168.8.0/22 to 150.100.0.0/16?
What I think is that the only explanation is that their VPN may not be constantly on and they initiate it on demand. But then, until the timeout is reached, they should not be able to connect, even if they enable it from their side or? The communication with them is difficult.
They say "We can connect". After some time I open Winbox, connect to the router and see "no phase2" and PH2 count = 0.
The log in the Mikrotik fails to provide adequate info when some IPSec event have happened, except the initiation of IPSec connection.
I don't understand how:
1. The VPN says no phase2
2. They claim that they can access the machines from their network.
3. I see traffic in the firewall rule 150.100.0.0/16 to 192.168.8.0/22
I see some megabytes traffic between 150.100.0.0/16 and 192.168.8.0/22 and from 192.168.8.0/22 to 150.100.0.0/16
Even if I put other router connected to eth2/LAN/ to the switch and from there they access their machines, thus making paralel connection and bypassing, this traffic should not be passing thru my gateway 192.168.8.40 to say it.

sindy · Wed Oct 28, 2020 10:24 pm

What I think is that the only explanation is that their VPN is not constantly on. They initiate it on demand.

This sounds reasonable. To verify that assumption, you can make a duplicate of the filter rule add action=accept chain=forward comment="P2" dst-address=192.168.10.0/22 src-address=150.100.0.0/16 (right next to it) and add ipsec-policy=in,ipsec to one copy and ipsec-policy=in,none to the other one. Then reset counters in both, and see which one will be counting packets.

So, before masquerade I need a rule that says
accept srcnat 192.168.8.0/22 to 150.100.0.0/16?

If it's only clients in their network connecting to you, and not vice versa, you don't need that rule. But nor do you need the one with src-address=150.100.0.0/16 - it should be showing 0 packet count in the srcnat chain.

techclerk · Wed Oct 28, 2020 10:35 pm

But nor do you need the one with src-address=150.100.0.0/16 - it should be showing 0 packet count in the srcnat chain.

Well, the rule accept 150.100.0.0/16 says 78 packets matching and about 4KB traffic.
If they initiate the VPN on demand, shouldn't I be able to see some number in PH2 count?
And if the connection is initiated, but no SA-s are exchanged, then they turn on the VPN on their side, how they can access the machines? Isn't it true that the VPN should first reach timeout, then reconnect, then exchange of SA-s, then encryption and connection? It stays ESTABLISHED in Active Peers all the time. Or they can turn it on on their side whenever they please and then disconnect and then when the Mikrotik is no longer able to exchange SA-s it says PH2 count=0, without even mentioning the previous successful connection?
Is PH2 count a value from the last successful exchange and if the next fails it resets to 0 or a value increased from the start of phase1/Established/ in Active peers and it counts all PH2-s even if there aren't anymore?
Because, there is no way for them to access my local net without DST-nat from their IP to my, bypassing the firewall. And I don't have such a rule.
The only DST-nat rules I have are some for some of my computers to be able to access particular sites, bypassing the address list filter.
And they are something like 192.168.8.10 to yahoo.com, port 80 and 443, action dstnat

sindy · Wed Oct 28, 2020 11:05 pm

Well, the rule accept 150.100.0.0/16 says 78 packets matching and about 4KB traffic.

Ah, sorry, assuming you talk about the one in srcnat - yes, it doesn't match on any out-interface, so it can count even for incoming conections from them, where the out-interface is your LAN. So there were 78 connections so far (only the first packet of each connection hits this rule).

If they initiate the VPN on demand, shouldn't I be able to see some number in PH2 count?
...
Is PH2 count a value from the last successful exchange and if the next fails it resets to 0 or a value increased from the start of phase1/Established/ in Active peers and it counts all PH2-s even if there aren't anymore?

Yes, PH2 count shows the number of currently established SA pairs as I wrote above. You can have multiple SAs between the same pair of peers:

[me@myTik] > ip ipsec active-peers print
Flags: R - responder, N - natt-peer
 #    ID                   STATE              UPTIME          PH2-TOTAL REMOTE-ADDRESS                                                     DYNAMIC-ADDRESS
 0    192.168.71.2         established        1w1d11h32m26s           2 192.168.71.2
 1  N 192.168.213.1        established        3h16m57s                5 187.93.26.11
 2 R  192.168.132.2        established        3h16m50s                6 192.168.132.2
 3    192.168.71.1         established        1h54m7s                 1 192.168.71.1

And the hierarchy is such that the "control session" (phase 1) may stay up but the SA for the actual payload transport (phase 2) may only be established on demand. So yes, their implementation may behave like this. The filter rules' modification I've suggested above can confirm this.

You can try to ping IPs in their subnet from an IP in yours (if you add that rule I've suggested above to the srcnat chain); even though their firewall may not let the ping in, the SAs should appear while you'd be pinging as Mikrotik can also create them on demand. You should see more in the log if you set /system logging add topics=ipsec,!packet. But it could be their system doesn't accept SA creation request from the peer.

techclerk · Wed Oct 28, 2020 11:11 pm

Yes, PH2 count shows the number of currently established SA pairs as I wrote above. You can have multiple SAs between the same pair of peers:

So, PH count is the number of currently established SA-s, not total number. And If they disconnect, the Mikrotik tries to establish new PH2 without waiting the timeout for the session, but fails and resets to 0. It's not a total number of exchanges SA-s. Then, maybe there is no problem after all, but I am unable to track exactly when they have established PH2 connection, because the log is not providing this kind of info. Then maybe I am not such an idiot.
P.S They have disabled ping. Trying to play too secure. And I have no access to their network. Blame their firewall.
If I edit the filter rules, so they can access only 2 specific machines, would this be ok?
They need to have access to 2 specific machines, that are not computers, but some proprietary equipment. They support it and it's in my network.

sindy · Wed Oct 28, 2020 11:40 pm

I am unable to track exactly when they have established PH2 connection, because the log is not providing this kind of info.

If you enable IPsec logging as shown above, you'll see it there, but there will also be a lot of extra information.

P.S They have disabled ping. Trying to play too secure. And I have no access to their network. Blame their firewall.

That doesn't prevent Mikrotik from attempting to establish an SA - the firewall which drops your ping request is on their side, so the Mikrotik sees the ping request first, and attempts to establish an SA for it. Whether their equipment accepts the request to establish an SA is another question of course.

If I edit the filter rules, so they can access only 2 specific machines, would this be ok?

Not just OK, highly recommended. You should not let them access anything more than what they need to access.

Other than that, you may save some CPU by rearranging your firewall rules - the "accept related, established" should be the topmost one, so only initial packets of all connections would be inspected by the other rules. The "accept established" doesn't match on the first packets of connections, but once the first packet of a connection is accepted, the first response to it makes the connection "established" still before the response reaches the filter, and from then on all the packets of that connection are accepted by the "accept established" rule.

techclerk · Wed Oct 28, 2020 11:58 pm

Other than that, you may save some CPU by rearranging your firewall rules - the "accept related, established" should be the topmost one

One more question. I had numerous attacks from the WAN side, trying to log in via SSH/TELNET/WinBox and Webfig. I just disabled the service ports and for the others I used an input rules to filter them if they are coming from WAN. Is my config correct? I saw drastic decrease in attacks after this actions.
With numerous I mean the moment I installed the router and connected it to the internet, the attacks started and the next day half of the log was red.
I didn't even suspect that our public IP is so popular. I also changed the default username and password with extremely complex ones.
What I am aiming is to make it unavailable for intrusions from WAN. I don't need to access it via WAN to configure it. I have some VPN software on my workstation and from there I can open Winbox and do whatever I need.
And I have to say that I am extremely grateful for your help. You have explained to me some things have otherwise vague definitions in the sources.
About the router, I have replaced a Hex with RB3011. Plenty of CPU, but I will definitely consider your advices.

sindy · Thu Oct 29, 2020 8:33 pm

The default firewall configuration of the SOHO product line permits no incoming connections at WAN except ICMP, neither to the router itself nor to devices on its LAN.
Below is the default firewall filter setup of the 3011 (from 6.45.7, Mikrotik keeps improving the default config) with a suggestion where to place custom rules:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
...add custom rules permitting incoming connections to router itself via WAN here (incoming IPsec or other VPN connections) ...
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"

add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
...add permissive rules for incoming connections coming in via WAN via IPsec here...
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

The last rule in chain forward is a generic one and drops all connection attempts except those that have been dst-nated in the NAT table, so it is enough to let the dst-nat rules match on src-address(-list) in the SOHO setups where there is a NAT.

The red rules prevent connections which need to be handled by IPsec from being fasttracked by the rule just below them; the assumption here is that IPsec is used to link branch offices to each other. For your use case, they are too wide; in my opinion, the best way is to add connection-state=established,related also to these red rules, and then add individual permissive rules matching on in-interface-list=WAN ipsec-policy=in,ipsec and corresponding src-address(-list) and/or dst-address(-list) for each connection type you want to permit via IPsec.

IPSec tunnel no phase2

IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2

Re: IPSec tunnel no phase2