IPSec NAT Source Address

RouterOS General
1

Hi!
Sorry for my poor English. I have problem
R1 and R2 connect each other with IPsec and IPIP tunnel. On R1 created rule NAT masquerade to get internet from R3 to PC1 and this is problem, i need that SRV1 see real IP of PC1 (192.168.6.20) and R3 see PC1 (192.168.6.20) as R1 (192.168.0.25) What rule on R1 I need to do?

R1

/interface ethernet
set [ find default-name=ether1 ] comment=LAN
set [ find default-name=ether2 ] comment="WAN Silikatnaya"
/interface ipip
add !keepalive local-address=10.1.1.1 name=ipip-tunnel1 remote-address=10.1.1.2
/ip neighbor discovery
set ether1 comment=LAN
set ether2 comment="WAN Silikatnaya"
/ip ipsec proposal
add auth-algorithms=md5 enc-algorithms=aes-128-cbc name=vpn
/ip address
add address=192.168.0.25/24 interface=ether1 network=192.168.0.0
add address=10.1.1.1/24 interface=ether2 network=10.1.1.0
/ip firewall filter
add chain=input dst-port=500 protocol=udp
add chain=input protocol=ipsec-esp
add chain=input protocol=ipencap
add action=drop chain=input in-interface=ether2
add action=drop chain=forward in-interface=ether2
/ip firewall nat
add action=masquerade chain=srcnat
/ip ipsec peer
add address=10.1.1.2/32 enc-algorithm=aes-128 hash-algorithm=md5 nat-traversal=no secret=****
/ip ipsec policy
add dst-address=10.1.1.2/32 proposal=vpn sa-dst-address=10.1.1.2 sa-src-address=10.1.1.1 src-address=10.1.1.1/32 tunnel=yes
/ip route
add distance=1 gateway=192.168.0.35
add distance=1 dst-address=192.168.6.0/24 gateway=ipip-tunnel1

R2

/interface ethernet
set [ find default-name=ether1 ] comment=WAN
set [ find default-name=ether2 ] comment=LAN
set [ find default-name=ether3 ] master-port=ether2
set [ find default-name=ether4 ] master-port=ether2
set [ find default-name=ether5 ] master-port=ether2
/interface ipip
add !keepalive local-address=10.1.1.2 name=ipip-tunnel1 remote-address=10.1.1.1
/ip neighbor discovery
set ether1 comment=WAN
set ether2 comment=LAN
/ip ipsec proposal
add auth-algorithms=md5 enc-algorithms=aes-128-cbc name=vpn
/ip address
add address=10.1.1.2/24 interface=ether1 network=10.1.1.0
add address=192.168.6.1/24 interface=ether2 network=192.168.6.0
/ip firewall filter
add chain=input dst-port=500 protocol=udp
add chain=input protocol=ipsec-esp
/ip ipsec peer
add address=10.1.1.1/32 enc-algorithm=aes-128 hash-algorithm=md5 nat-traversal=\
    no secret=****
/ip ipsec policy
add dst-address=10.1.1.1/32 proposal=vpn sa-dst-address=10.1.1.1 \
    sa-src-address=10.1.1.2 src-address=10.1.1.2/32 tunnel=yes
/ip route
add distance=1 gateway=ipip-tunnel1

MK.jpg

2

Make your masquerade rule more specific so it does not translate what you don’t want it to translate.
This can be done using Src.address and Dst.address fields, the output interface, and also you can add
a second rule with the conditions you do NOT want to translate and do action “accept” in that rule.

3

Thanks, add this line on R1 and all work

add chain=srcnat dst-address=192.168.0.0/24
4

Another way would be to make your srcnat rule only reference the WAN interface at each site.
Since you’re using IPIP tunnels, site-to-site traffic technically doesn’t go through the WAN interface, but the IPIP interface.

e.g.
/ip firewall nat
add chain=srcnat out-interface=ether1-gateway action=masquerade

This is the cleanest method in my opinion because it describes the policy: “Use my public IP as the source when going on the Internet,” but it doesn’t get bogged down with specific IP addresses. If you add more sites, then no changes are needed. If you decided to start using other internal IP ranges, no changes are needed. It also has the added bonus of adaptability because R2 can have the primary default GW be through the IPIP tunnel to R1, but have a backup default GW directly to the Internet, so if R1 goes down or loses its Internet connection, PC1 can still use the local Internet.

5

I agree with that. I think it is also the default configuration.
Unfortunately it does not work with “IPsec tunnels” because there is no separate virtual interface for the tunnel.
But indeed with IPIP tunnels it works OK. In fact, it is often better to use IPIP over IPsec transport than to use
IPsec tunnel mode, because of the issues there are in the Linux/RouterOS implementation. Of course, the other
side has to agree with that.

6

Not to mention the fact that you can run routing protocols on the tunnel interface and have arbitrary dynamic topology on the other side without having to maintain a list of selectors. I really really really dislike raw IPSec.

7

Unfortunately there are no multipoint tunnel protocols in RouterOS (IPIP mesh, multipoint GRE, NHRP etc) so it does
not scale well and is hard to make a roadwarrior VPN.