Community discussions

MUM Europe 2020
 
rbax
just joined
Topic Author
Posts: 1
Joined: Wed May 01, 2019 1:37 am

Customers IPSEC tunnel comes up, won't pass tunneled traffic through my Mikrotik

Wed May 01, 2019 2:02 am

I am trying to pass IPSEC traffic through a router that is doing NAT and routing public IPs. It appears to be dropping the tunneled traffic on the floor and I can't figure out why. Public IPs changed for security. My config is below. I welcome all input. =)
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=Internet list=WAN
/ip address
add address=10.64.0.1/23 interface=bridge network=10.64.0.0
add address=2.2.2.2/28 interface=bridge network=2.2.2.0
add address=1.1.1.2/30 interface=Internet network=1.1.1.1

/ip firewall filter
add action=accept chain=forward dst-address=2.2.2.2/28 in-interface=Internet out-interface=bridge
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add chain=input comment="accept IPsec ESP" in-interface=Internet protocol=ipsec-esp
add action=accept chain=input comment="ICMP Allow" protocol=icmp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=established,related,untracked
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/ip route
add distance=1 gateway=1.1.1.1
 
McSee
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Tue Feb 26, 2019 12:49 pm

Re: Customers IPSEC tunnel comes up, won't pass tunneled traffic through my Mikrotik

Fri May 03, 2019 12:54 am

One thing I've noticed that might need attention is that you NAT outgoing traffic to the internet from public 2.2.2.2/28 addresses.
 
Sob
Forum Guru
Forum Guru
Posts: 5000
Joined: Mon Apr 20, 2009 9:11 pm

Re: Customers IPSEC tunnel comes up, won't pass tunneled traffic through my Mikrotik

Fri May 03, 2019 4:47 am

Also "/ip firewall filter" doesn't really do much, accepts all around and in the end everything is allowed.

The only exception is one rule with action=fasttrack-connection, and about that:
FastTracked packets bypass firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow(restriction removed in 6.33), IP accounting, IPSec, hotspot universal client, VRF assignment, so it is up to administrator to make sure FastTrack does not interfere with other configuration;
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
sindy
Forum Guru
Forum Guru
Posts: 4216
Joined: Mon Dec 04, 2017 9:19 pm

Re: Customers IPSEC tunnel comes up, won't pass tunneled traffic through my Mikrotik

Fri May 03, 2019 7:37 pm

As you have posted only part of the configuration, it is not really clear whether the Mikrotik itself uses IPSec policies to catch plaintext traffic and encrypt it or whether the problem is transit of IPsec transport traffic between two other devices through that Mikrotik. Catching traffic using policies doesn't make friends with fasttracking as @Sob wrote but the symptoms are not that all packets are dropped, only 99% of them which allows TCP sessions to work but really slow.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
sindy
Forum Guru
Forum Guru
Posts: 4216
Joined: Mon Dec 04, 2017 9:19 pm

Re: Customers IPSEC tunnel comes up, won't pass tunneled traffic through my Mikrotik

Fri May 03, 2019 9:53 pm

Answering to myself - as you speak about "Customer's IPsec tunnel", I conclude that the customer runs his own IPsec peer on one of those 2.2.2.x addresses against some remote IPsec peer.

If that is really the case, the fact that outgoing connections initiated by 2.2.2.x are not excluded from your your action=masquerade rule may be the root cause of the trouble in the following scenario:
  • the customer's device listening at 2.2.2.x acts as an IPsec responder, so the initial IKE or IKEv2 packet comes from the remote side. Hence you forward it to the customer's device without passing through any NAT rule and thus your Mikrotik firewall's connection tracker establishes a connection without any NAT handling for the IKE session(s).
  • thanks to the above, the IKE NAT-T detection doesn't detect any NAT between the peers, and so the peers choose ESP to transport the encrypted payload
  • the customer's device is the first one to send an ESP packet towards the remote one; as there is no tracked connection yet for this ESP exchange in your Mikrotik's connection tracker, this first packet is matched by the action=masquerade rule and the source address of the packet is changed from 2.2.2.x to 1.1.1.2, which causes the remote device not to accept it (or, if another ESP communication is already in progress on 1.1.1.2, the connection is not created an the packets are not getting through because there woudl be an unresolvable conflict, given that the firewall would be unable to identify to which of the two connections a received ESP packet for 1.1.1.2 belongs and forward it appropriately. The SPIs differ per direction and are negotiated encrypted so there is no way to match the packet to one of the connections by its SPI value.
If the above is what actually happens, it is enough to add src-address=!2.2.2.0/28 to your action=masquerade rule, and then use /ip firewall connection remove where protocol~"ipsec" and srcnat to remove the existing connection with srcnat handling activated. The match pattern for the protocol field in the remove command is ipsec because the same what I've described for ESP would happen for AH as well.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 98 guests