IPSec tunnel trought Intenet with remote site working on dynamic IP address

Hi,
I’m trying to setup ipsec tunnel between “HQ” working on Mikrotik CCR with fixed IP address and “Remote” site working on tp-link LTE router with dynamically assigned IP address.

To another remote location with static IP is working without any problem - the problem is only with dynamic.

I found that ipsec peer should have Address 0.0.0.0/0 to work in this case and generate-policy should be port override.

All encryption parameters are the same on both sites, but it’s not working.

Do somebody can give me a hint how to do it?

Regards

If you post /ip ipsec export hide-sensitive from both machines (and replace the public address of the HQ by hhh.hhh.hhh.hhh before posting), someone may find the mistake. Post the equivalent settings from the TP-link of course.

BTW there is no reason why policy-generate could not be set to port-strict if one of the peers is on dynamic address.

On Mikrotik I have IPSec configuration

/ip ipsec export hide-sensitive

jul/04/2018 13:21:52 by RouterOS 6.42.3

software id = PYX6-6GV1

model = CCR1009-7G-1C-1S+

/ip ipsec policy group
add name=connection
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des
pfs-group=none
add enc-algorithms=aes-128-cbc lifetime=1h name=Connection
/ip ipsec peer
add address=0.0.0.0/0 comment="dynamic Connection" dh-group=modp1024
dpd-interval=disable-dpd enc-algorithm=aes-128 exchange-mode=aggressive
generate-policy=port-override lifetime=1h local-address=hhh.hhh.hhh.hhh
policy-template-group=connection
/ip ipsec policy
add comment="Template for dynamic connection" group=connection
proposal=Connection template=yes

On TP-link router in remote site I have :
Dead Peer Detection: disabled
Remote IPSec Gateway (URL): hhh.hhh.hhh.hhh
Tunnel access from local IP: 10.186.224.0 subnet 255.255.255.0
Tunnel access from remote IP: 192.1.10.0 subnet 255.255.254.0
Key exchange Method: Auto (IKE)
authentication method: pre-shared key
pre-shared Key: KEY_FOR_IPSEC_CONNECTION
Perfect Forward Secrecy: disable
Phase 1
Aggressive, aes-128, sha1, 1024bit, 3600 seconds
Phase2
aes-128, sha1, 1024bit, 3600 seconds
There is no more configuration for IPSec on tplink

with this configuration I have ipsec PH2 state established and on tp-link status is UP, but still have no connection beetween sites.

I have on firewall/NAT rules
add action=accept chain=srcnat comment="allow connection" dst-address=
10.186.224.0/24 src-address=192.1.10.0/23
add action=accept chain=srcnat comment="allow connection" dst-address=
192.1.10.0/23 src-address=10.186.224.0/24

@sindy I have checked a lot of combinations and with port-strict it wasn't working

Regards

  • the NAT rule action=accept chain=srcnat comment=“allow connection” dst-address=192.1.10.0/23 src-address=10.186.224.0/24
    is not necessary as you need to create an exception from src-nat only for the 'Tik (192…) → TPlink (10…) traffic.
  • the NAT rule action=accept chain=srcnat comment=“allow connection” dst-address=10.186.224.0/24 src-address=192.1.10.0/23 must be placed before any action=src-nat rule to shadow it for the packets which need to be recognized by the policy.
  • for the 'Tik, the packets which came through the IPsec tunnel inherit the in-interface from the transport packets inside which they came encapsulated. So if your /ip firewall filter table contains rules which prevent local reception (chain=input) or forwarding to LAN devices (chain=forward) of packets which came in through the WAN interface, you need to set up an exception from them by adding a rule with action=accept ipsec-policy=in,ipsec at appropriate position in both chains (or only to chain=forward if you don’t plan to access the 'Tik itself via the tunnel)
  • if the TP-link is on a dynamically assigned IP address but it has it directly on itself, i.e. there is no NAT device between the TP-link and the internet, make sure that there is a rule action=accept chain=input protocol=ipsec-esp in your /ip firewall filter right above or below the one accepting protocol=udp dst-port=500,4500.

If all the above is set properly and it still does not work, let the tunnel establish, ping some device in 'Tik’s LAN (not the 'Tik itself) from the TP-link side, and post the output of /ip ipsec policy print and /ip ipsec installed-sa print after replacing the public addresses by hhh.hhh.hhh.hhh and ccc.ccc.ccc.ccc.

Thanks sindy for your answers.
Unfortunately adding rules has no effect :frowning: Something is wrong, but have no idea what.
The TP-link router have LTE card, so it's possible that the mobile provider have NAT between our router and Internet.
I have called provider and they told me that there is NAT from LTE to Internet - is it possible to create IPsec site-to-site in this case?
If yes please look below.
I put firewall rules for this connectoion on the first positions, but still not working.
Below I put all configuration involved in this communication, maybe You will find a bug or misconfiguration.
/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active,

    • default
      0 T * group=default src-address=::/0 dst-address=::/0 protocol=all
      proposal=default template=yes
      3 T ;;; Template for MyConnection
      group=connection src-address=::/0 dst-address=::/0 protocol=all
      proposal=Connection template=yes
      4 DA src-address=192.1.10.0/23 src-port=any dst-address=10.186.224.0/24
      dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp
      tunnel=yes sa-src-address=hhh.hhh.hhh.hhh sa-dst-address=ccc.ccc.ccc.ccc
      proposal=Connection ph2-count=1

/ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
2 R ;;; for MyConnection
;;; Unsafe configuration, suggestion to use certificates
address=0.0.0.0/0 auth-method=pre-shared-key secret="MY_KEY"
generate-policy=port-override policy-template-group=connection
exchange-mode=aggressive send-initial-contact=yes nat-traversal=yes
proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-128
dh-group=modp1024 lifetime=1h dpd-interval=disable-dpd

/ip ipsec proposal print
Flags: X - disabled, * - default
0 * name="default" auth-algorithms=sha1
enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des lifetime=30m
pfs-group=none
2 name="Connection" auth-algorithms=sha1 enc-algorithms=aes-128-cbc lifetime=1h
pfs-group=modp1024

/ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
2 HE spi=0x5529AE8 src-address=ccc.ccc.ccc.ccc dst-address=hhh.hhh.hhh.hhh state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="d38c5d34d0e350b117559b3bbbeec3cb568b"
enc-key="751d2e64936b25b09604263328f1" addtime=jul/05/2018 09:43:01 expires-in=45m18s add-lifetime=48m/1h
current-bytes=848 current-packets=8 replay=128

3 HE spi=0xDA3B870 src-address=hhh.hhh.hhh.hhh dst-address=ccc.ccc.ccc.ccc state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="8c34ee6569a91a28ec651a1564fba5b05c90"
enc-key="f33dc25b8228e3b66e9181197049" addtime=jul/05/2018 09:43:01 expires-in=45m18s add-lifetime=48m/1h
current-bytes=616 current-packets=7 replay=128

that's all from IPSec part

The firewall part

/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Allow for MyConnection
chain=input action=accept tcp-flags="" protocol=ipsec-esp src-address=10.186.224.0/24 dst-address=192.1.10.0/23
log=yes log-prefix="Allow for MyConnection"

1 ;;; Allow for MyConnection
chain=input action=accept tcp-flags="" protocol=ipsec-esp src-address=192.1.10.0/23 dst-address=10.186.224.0/24
log=yes log-prefix="Allow for MyConnection"

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; allow MyConnection
chain=srcnat action=accept src-address=10.186.224.0/24 dst-address=192.1.10.0/23 log=yes log-prefix=""
1 ;;; allow MyConnection
chain=srcnat action=accept src-address=192.1.10.0/23 dst-address=10.186.224.0/24 log=yes log-prefix=""
4 chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

I was also trying something with Raw
/ip firewall raw print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=prerouting action=notrack log=no log-prefix="" src-address=192.1.10.0/23 dst-address=10.186.224.0/24
1 chain=prerouting action=notrack log=no log-prefix="" src-address=10.186.224.0/24 dst-address=192.1.10.0/23

I was also trying to setup IP tunnel for this connection, but have no idea how to put destination dynamic address :frowning:, so I put local network IP
/interface ipip print
Flags: X - disabled, R - running, D - dynamic

NAME MTU ACTUAL-MTU LOCAL-ADDRESS REMOTE-ADDRESS KEEPALIVE DSCP

1 R ;;; Tunel for MyConnection
MyConnection-ipip-tunnel1 auto 1480 0.0.0.0 10.184.224.0 inherit

That's all what I have configured to connect with this remote site.
Do you have any idea what to do more?

There are several points which are unclear and could be guilty. My candidate No. 1 is … No. 1 in the list below :slight_smile:

  1. The very first permissive rule in your /firewall filter permits only ipsec-esp protocol from the TP-link’s private subnet to 'Tik’s one - that’s a nonsense. Each received IPsec transport is handled by the firewall filter as-is, hence you need to permit ESP in the input chain; the actual packet decrypted and unpacked from the transport one is handled by the firewall one more time as if it came in through the same interface. The ESP packets flow between the public addresses; the actual packets retrieved from them are of normal protocols such as TCP, UDP etc. So if the firewall is otherwise properly restrictive (drop anything what has not been explicitly permitted), the retrieved packets don’t get through the filter. So replace “protocol=ipsec-esp” by “ipsec-policy=in,ipsec” in this rule, this condition matches packets which have been obtained by unpacking of an IPsec transport packet. And copy the same rule (after modification) also to the beginning of chain=forward because in chain=input, it only permits packets to the 'Tik’s own address, not to other LAN devices.
  2. You have censored out some “unrelated” policies from the data you’ve posted; I first thought they were templates but as you have filtered out also some installed-sa, I assume at least one of those policies not posted is a real working one. Check whether it doesn’t shadow the one towards the TP-link client (id=3 in your posting). It should be fine as there are some current-bytes and current-packets in the printout of SA from the 'Tik to the TP-link, but better double-check.
  3. I can see the src-address and dst-address in /ip ipsec installed-sa print to show no port number (:4500 after the IP address). If this is real and not a consequence of your overactivity when obfuscating, then the TP-link has ccc.ccc.ccc.ccc directly on itself so plain ESP (not encapsulated into UDP) is used. In any case the SAs are working as you can see some current-bytes and current-packets in the printout. As these exist in the TP-link → 'Tik SA, it means that the transport packets did make it through the internet.

I didn’t get the idea of the IPIP tunnel (does the TP-link support it too?) so I don’t comment on it until you provide a feedback on whether the change of the /ip firewall filter rule No. 0 in the printout and its copying to chain=forward has helped or not.

I have modified firewall as you write in point number 1 ( I hope I did it correctly )
/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Allow MyConnection
chain=input action=accept tcp-flags=“” src-address=10.186.224.0/24 dst-address=192.1.10.0/23 log=yes log-prefix=“Allow MyConnection”
ipsec-policy=in,ipsec
1 ;;; Allow MyConnection
chain=forward action=accept tcp-flags=“” src-address=10.186.224.0/24 dst-address=192.1.10.0/23 log=yes log-prefix=“Allow MyConnection”
ipsec-policy=in,ipsec
2 ;;; Allow MyConnection
chain=input action=accept tcp-flags=“” src-address=192.1.10.0/23 dst-address=10.186.224.0/24 log=yes log-prefix=“Allow MyConnection”
ipsec-policy=in,ipsec
3 ;;; Allow MyConnection
chain=forward action=accept tcp-flags=“” src-address=192.1.10.0/23 dst-address=10.186.224.0/24 log=yes log-prefix=“Allow MyConnection”
ipsec-policy=in,ipsec

Ad.2 Yes I have cut off unimportant things - I have chcecked it as you write.
Ad.3 Yes It’s real, but where I can force to put it in the dynamic template? I have put it via WinBox IPsec/Policies in the Template for MyConnection, but after connection I still see that there is no port after IP address
I also observed that in the Winbox Remote Peers I have local port number 500 and remote port number is 6748 - in the Terminal it looks like that:
/ip ipsec remote-peers print detail
Flags: R - responder, N - natt-peer
0 R local-address=hhh.hhh.hhh.hhh remote-address=ccc.ccc.ccc.ccc port=6748 state=established side=responder uptime=10m18s last-seen=10m17s

Ad 1., better post the complete export of your firewall rules, as I assume that you’ve started from the default ones and it may not be the case. The fact that you feel the need to explicitly permit traffic originating on your LAN (and do it wrong) makes me cautious.

Ad 3.1., the src-address and dst-address in /ip ipsec installed-sa print are SA endpoints’ addresses, not policy’s match ones, so whether the port is or is not there says nothing about how the policy which is responsible for establishment of this SA handles ports; it merely tells you whether the SA uses plain ESP (which has no ports) or UDP-encapsulated ESP. The port-strict or port-override settings affect the dynamically created policy which is a mirror of the one indicated by the peer (if the peer requests particular ports, port-override creates a dynamic policy ignoring port numbers).

Ad 3.2., I have no idea how the TP-link’s implementation behaves regarding IKE ports. To see the whole story, you’d have to:

  • issue /system logging add topics=ipsec,!packet (unless done already)
  • switch off the TP-link or disable the IPsec on its side
  • issue /log print follow-only file=ipsec-start where topics~“ipsec”
  • start the TP-link or enable IPsec on it, wait until the installed-sas appear, then break the /log print …
  • download the file and read it; before eventually posting it, use find&replace to obfuscate public IPs

.

Hello Sindy,
It take me some time to reply for your answer, but finally I have downloaded ipsec-start file and complete export of firewall rules.
In the meantime I have configured L2TP connection from remote location with dynamic IP to my hhh.hhh.hhh.hhh address and everything is working correctly.
For collecting of logs the L2TP connection was disabled and there was no ipsec packets for it.
Files are attached.
Reagrds
Adam
ipsec-start-ready.txt (170 KB)
firewall-full.txt (5.26 KB)

The contents of the log file contradicts what you wrote in the text. The log contains two successful establishments of an IPsec tunnel for secure transport of the L2TP but no other IPsec connection attempt.

What exactly have you disabled about the L2TP when taking the log?

Maybe the TP-link box says “IPsec” but actually means “L2TP/IPsec”?

I have configured L2TP connection which is reconnected in remote server scheduler every five minutes. I have killed L2TP connection so there was no SAs and restart the TP-Link router.
It takes me definitely less than five minutes so it was no possible to establish L2TP/IPsec - that should be packets from site-to-site VPN connection.
I’m sure that this TP-link have site-to-site vpn (not only L2TP/IPsec) - even on the tp-link website is an example with my router model Archer MR200 (link below).
https://www.tp-link.com/lb/faq-1661.html

I don’t search for any fight :slight_smile: What I’ve written is merely what I’ve seen in the log. All the three connection attempts there came from the same remote address and port, so from the same source device; whether it was the TP-link or something else behind the same public IP is out of my knowledge. And the two of them which have succeeded have installed a security association for UDP only between h.h.h.h:1701 and c.c.c.c:1701 which is clearly one for encrypted transport of L2TP, and two seconds after a successful establishment, the remote peer has started another connection attempt which suggests that some higher layer protocol, like the L2TP itself, failed to do its job - which is the reason why I’ve suspected you may have only disabled the L2TP server at Mikrotik side, not at the client side. Also, the initial communication contains a vendor ID of Microsoft, which I doubt TP-link would use in its products:
14:05:51 ipsec IPSEC → : received long Microsoft ID: MS NT5 ISAKMPOAKLEY

But all that is not important. You haven’t taken a standpoint to my point 3. in the list of possible causes. So again - unless it is a consequence of your obfuscation, the installed-sa show only the IP address but no port, which means that the NAT detection has failed, which has caused Mikrotik to send and expect data using plain ESP while the other peer may well send and expect them as UDP-encapsulated ESP. I don’t know why it happens (even between two Mikrotiks) and I think it is a bug, but to my surprise Mikrotik support had a relaxed appproach to it, saying it “sometimes happens”.

So please double-check that the SAs really belong to the TP-link connection and that it happens every time, and then I’ll suggest you an ugly hack which may or may not help depending on how good the TP-link side is.