IPsec and Router's Src. Address

Hello Everyone.

I have implemented few IPsec connections between our main office and remote branches.
Everything as usual Site-to-Site VPN, pure IPsec, policy indicating which sources to which destinations do encrypt with specific proposal.

Policy:

1 ;;; Location 1 IPSec
src-address=172.16.0.0/23 src-port=any dst-address=172.16.32.0/24 dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=X.X.X.X sa-dst-address=Y.Y.Y.Y proposal=Location_1_Proposal
priority=0

Unfortunately when router itself tries to access remote network, it can’t recognize which source IP address to use.
Thus in order to make a simple ping from the router on one side to the host on another side it forms the IP packet, where uses its public IP address as source, giving no chance to go through the IPsec tunnel.

We have few services where our remote routers need to have access and I do not want use NAT to allow this.
Maybe there is some workaround or option that I have not considered before?

Thank you for answers.

Use the “src-address=” option when you tell the router to ping across the tunnel with what source address you wish for it to use. Otherwise it will choose the preferred source of the default route with the least amount of weight.

What services are you looking for to use across the tunnel within the router? Not all, but several of them do allow you to specify a source address. If not, then you need to use NAT.

Thank you for reply. Somehow I did not think about this option in services, but successfully tested it in Ping.
I need DNS, Radius and DHCP for the moment.

For RADIUS I see now it is possible to set Src. IP.
What shall I do for DHCP relay? And what shall I do for DNS?

I have tried NAT, unfortunately it did not work. As I’ve understood from the packet flow, NAT is after IPsec.

You can try Local Address for DHCP relay. I don’t use DHCP-Relay so I am not sure on that one, but what I would do is setup torch on that interface to watch the traffic leave and determine what the traffic is being sent out as, and try to modify it via source NAT. The same thing for DNS requests from the router.

If this doesn’t get you to where you want to be, the next step in my mind would be to create another IPSec policy that would specifically match the public interface of the Mirotik and where it is trying to reach, instead of just the internal LAN network.