Hello, I’ve tried to setup L2TP/IPsec vpn on my router. I can successfully access them through my LAN but when I tried to access them through 4G it fails.
My log below:
13:13:49 ipsec,info respond new phase 1 (Identity Protection): xxx.xxx.xxx.xxx[500]<=>175.176.67.122[28729]
13:13:52 ipsec,info the packet is retransmitted by 175.176.67.122[28729].
13:13:55 ipsec,info the packet is retransmitted by 175.176.67.122[28729].
13:13:58 ipsec,info the packet is retransmitted by 175.176.67.122[28729].
13:14:01 ipsec,info the packet is retransmitted by 175.176.67.122[28729].
13:14:04 ipsec,info the packet is retransmitted by 175.176.67.122[28729].
13:14:19 l2tp,info first L2TP UDP packet received from 175.176.67.122
13:14:49 ipsec,error phase1 negotiation failed due to time up xxx.xxx.xxx.xxx[500]<=>175.176.67.122[28729] dbaab16a73dbc420:29
d30f82da568583
Where x is my static IP and 175.176.67.122 is my ip from 4G
First of all, your firewall doesn’t protect the Mikrotik itself from remote connections to its management interfaces (ssh, winbox, webfig) or from acting as a DNS attack amplifier, because there is no action=drop rule in chain input of /ip firewall filter. In RouterOS, the default action in all chains is accept, so whatever is not matched by one of your accept rules is accepted anyway. Even for the LAN devices, a NAT on WAN does not substitute proper firewall rules in chain forward.
Second, the log suggests that the device connected to 4G doesn’t receive the responses from the Mikrotik, which makes it retransmit the initial request.
So I would sniff the traffic on the WAN interface, matching on the 4G IP address, to see whether the Mikrotik actually responds or not, and if it does, what is the size of the response packets and whether they are fragmented.
If the connecting client doesn’t have a 4G modem directly on itself but is connected to it via Ethernet or WiFi, I would also sniff on the client using tcpdump or Wireshark, matching on the public address of the Mikrotik, to see whether the responses from Mikrotik reach the client or not.
My experience is that this issue is caused by (CG)NAT routers on the path maintaining incorrect state or making incorrect port translations.
The remote sends you the IPsec packet but it does not receive the reply on the port number where it is listening.
You can already guess that is wrong by looking at: xxx.xxx.xxx.xxx[500]<=>175.176.67.122[28729]. that 28729 should be 500 as well, but NAT has translated it. The NAT should translate it back to 500 but does not do that correctly, e.g. when two different connections were made.
When this happens only occasionally (and especially during testing when you are trying different scenarios like breaking the connection after it was established), it can sometimes help to shut the client down for a couple of minutes and then starting it again. The incorrect NAT rule has expired by then (usually after 3 or 5 minutes).
When keeping the client on (and trying), the bad situation persists.
Btw, thanks for all the answers above and an update here is that it worked I disable my main ISP (I have dual isp, main ISP is on ether1 and DHCP while ether6 is ppp client with static ip) so basically if ether1 is enabled it will retransmit the data.
That changes a lot. Normally I would just refer to this, but for your case, it is a bit more complicated as you use connection marks for QoS purposes, and in the RouterOS implementation, a single connection cannot have more than a single connection mark. So you’d need to use aggregate connection marks to use them for both QoS treatment and policy routing.
So for your case, I suggest the following routing rule: /ip route rule add src-address=ip.of.pppoe.wan action=lookup-only-in-table table=useonly_globe
As your Mikrotik acts as a responder (server) in the L2TP/IPsec connections, it sends the response traffic from the IP address to which the initial request of a given connection has arrived. So this rule will make sure that whatever is sent from the IP address of the PPP WAN will be routed through that interface. Without this rule, the response packets from that address are sent via ether1, and some ISP along the path drops them because they have an unexpected source address - if nothing else, the NAT at the initiator (client) end will drop them as they do not match any existing pinhole.
