srcnat affects ipsec traffic - right or wrong?

RouterOS General
1

I have a RB1000 running ROS 3.20 in a typical office setup. A local network on Ether1 and internet on Ether2 and are doing basic srcnat of traffic leaving on Ether2 like:

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether2 src-address-list=Local to-addresses=X.X.X.X

Then we added a simple ipsec tunnel to a remote office, connecting the local network with a remote network. Everything worked except that the above NAT rule seemed to affect also the traffic going from the local network into the ipsec tunnel, so traffic through the tunnel got NAT:ed and didn’t work. Adding an action=accept rule in the srcnat chain above that one that says that the traffic destinated for the remote IP network shouldn’t be nat:ed solved the problem.

My qustion is just, should it be this way? When working with OpenS/WAN on Linux I was used to have a ipsec0 interface that traffic going into a ipsec tunnel used as out-interface so srcnat rules with out-interface=physical-out-interface did NOT affect that traffic.

Over all I miss the ipsec interfaces. I’d like to simply setup ipsec tunnels and then have rules saying that traffic between the ipsec interface and local interface is allowed without caring about what IP address the packets are carrying.

2

Yes it should be that way. Always add accept rules for all ipsec traffic and only then add masquerade rules.

3

Thanks,

Well, I’ve been reading up on what has happend with IPsec in the Linux world the last years, and what I had missed was that many have moved from the KLIPS implementation I was used to work with which used virtual interfaces like ipsec0, to NETKEY which doesn’t use virtual interfaces at all.

Huge misstake in my opinion to drop the use of virtual interfaces, but anyway, since then it seems like NATing is simply supposed to work this way as the IPsec traffic is seen on the physical interface as well.

Not much of a problem with NAT:ing though as long as you know that this is how it works. A bigger problem is that you can’t write filter rules based on if traffic is going out/comming in on an ipsec interface any longer :frowning: But that’s another thread that I’m having discussions with the support about.