Thanks for the nice explanation
...
I made another scheduler for chain=srcnat PPTP_YD to keep it at #=1
...
I didn't change the action=masquerade dst-address-list=excluded-addresses cause I didn't understand this part completely.
This means the explanation may have been nice but actually it wasn't clear enough. So again.
The very purpose of adding
connection-mark=no-mark to the
mode-config row is that instead of rule
order in the
srcnat chain, the
presence or absence of a connection-mark would decide which packet will be handled by which rule - so there would be no need to move the rules around, using a scheduled script or otherwise.
My way, there will be just three rules in chain srcnat:
first, the dynamically added one:
action=srcnat src-address-list="Allow Local DNS" connection-mark=no-mark to-addresses=the.ip.from.responder
second and third, in any mutual order, the static one for traffic leaving via PPTP and the static one for the traffic leaving via the regular WAN (ether10 in your case):
add action=masquerade chain=srcnat comment=PPTP_YD out-interface=PPTP_YD src-address=192.168.11.94
add action=masquerade chain=srcnat out-interface-list=WAN
Their mutual order is irrelevant because no packet can match both
out-interface=PPTP_YD and
out-interface-list=WAN (unless you'd make
PPTP-YD a
member of
interface list WAN; if you did, the single rule matching on
out-interface-list=WAN would be enough, but please don't do that as it might break something else in the firewall). The dynamic rule must be first, though.
To make the dynamically created rule
ignore a packet, you have to assign some
connection-mark (no matter what particular value it will have) to that packet.
Since you want packets matching on
dst-address-list=excluded-addresses to be ignored by the dynamic srcnat rule, you must add a
dst-address-list=excluded-addresses action=mark-connection new-connection-mark=avoid-ipsec
rule to
/ip firewall mangle; to make it "safe", i.e. to make sure it would only assign a new
connection-mark value if none has been assigned to that connection yet, it should also match on
connection-mark=no-mark or
connection-state=new.
And my mistake was that I've written
nat/prerouting and
nat/output whereas the correct places are
mangle/prerouting and
mangle/output.
A rule in
mangle/prerouting handles traffic forwarded from LAN; a rule in
mangle/output handles packets sent by the Mikrotik itself, such as the PPTP transport ones.
when the IPSec is down PPTP is not connecting (if connected it will got terminating) when the "IPSec is killing ike2 SA" before it's get a "new ike2 SA (I)" for about 120 seconds PPTP is just trying to connect and if you remember I had a "IPsec-SA expired before finishing rekey" problem before you told me on another topic to set /ip ipsec proposal to pfs-group=none and it's fixed that "IPsec-SA expired before finishing rekey" problem but still there is "IPSec is killing ike2 SA" and I got a feeling this is a server configuration problem (Linux Ubuntu StrongSwan).
If there is no rule in
mangle/output (my way) or in
nat/srcnat (your previous way) that would exempt the PPTP transport packets sent by the Mikrotik itself from being src-nated to match the dynamically generated IPsec policy, it means that the PPTP transport packets to the remote PPTP server are sent via the IPsec policy. So when the Security Association (SA) linked to that policy is down, but the policy itself still exists, the PPTP transport packets get nowhere, as the policy diverts them but cannot actually deliver them.
2. Is this normal to having "IPSec is killing ike2 SA"? It's not very frequent though it's like at three days once or every other day.
It indeed looks like some incompatibility between the initiator and the responder, or maybe it indicates a huge data loss causing the rekey procedure to fail, ot maybe it's the refresh of the "control SA" (the one the peers use to negotiate and control establishment of the SAs carrying the payload) that fails. To say more, I would have to see the logs from both peers, including about 5 minutes before the "killing ike2 SA" messages appear in the log.