Weird IPSEC problem

RouterOS General
1

I’m trying to create an ipsec tunnel to a host where the destination subnet and remote public endpoint is both the same single public IP address, that is, it’s a seemingly simple config where they allow access to a single public address from our small local subnet.

The ipsec config looks like this:

/ip ipsec policy
add dst-address=1.2.3.4/32 proposal=prop1 sa-dst-address=1.2.3.4 sa-src-address=4.3.2.1 src-address=192.168.33.0/29 tunnel=yes

/ip ipsec peer
add address=1.2.3.4/32 enc-algorithm=3des,aes-128,aes-256 nat-traversal=no secret=xxx

/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=prop1

/ip firewall nat
add chain=srcnat dst-address=1.2.3.4 src-address=192.168.33.0/29

1.2.3.4 is the remote IP and subnet, 4.3.2.1 is the local public IP and 192.168.33.0/29 is the local subnet. Host on local network has IP 192.168.33.2/29 and is srcnatted to this address so packets get forwarded through the tunnel in the MT router.

The connection is built, 2 SAs for both directions are installed. But only one direction is able to transmit. Packets get tunneled, the local SA → remote SA direction counters are increasing, but the remote side can’t see the packets. No answers are coming back in the tunnel. I’m banging my head against the wall as I can’t figure out what’s wrong. Is this configuration supported at all? That is, local subnet → single remote IP policy mode?

I’m grateful for any hints. I’m running an RB2011UiAS-2HnD. The remote end is FreeSwan on Linux.

2

You need your /ip firewall nat rule (the bypass rule) to match the local and remote private networks.

So, if the local side is 192.168.1.0/24 and the remote side is 192.168.2.0/24, your NAT bypass rule would be as follows:

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.2.0/24

Obviously, on the far side, the local and remote would be reversed, so you would need to reverse the NAT bypass rule’s src-address and dst-address matchers. The NAT bypass needs to match all traffic that would go down the tunnel, so that it doesn’t get the source IP re-written by your normal WAN masquerade rule – otherwise, the computer on the far end won’t be responding to the correct IP (or would reject the traffic). MikroTik IPsec tunnels do not create a separate interface, so traffic looks to the firewall just like normal WAN traffic.

Similarly, the /ip ipsec policy dst-address matcher needs to match the “LAN network” of the remote side – the IPs the computers actually have. The sa-dst-address matcher will be the WAN (public) IP to connect the tunnel to.

3

DLNoah, I do appreciate the time you spent answering me, but could you please read my opening post again, because I feel that you missed all main points I’m needing some help with. Without repeating the whole thing: there is a single remote IP, no remote subnet; the local NAT rule is in place (although it’s possible that a modification is needed); the remote end is not an MT device but FreeSwan on Linux. Thanks!

4

Oops, my mis-read, sorry.

I’m used to mis-configuring it myself where I put the connect-to IP in instead of the remote-LAN IP, glossed over your opening statement, sorry.

Do you have a regular client connection that works with these settings? To me, the MT settings look correct and I’d be inclined to troubleshoot the remote end.

5

The remote end is a government institution that offers access to their test site via this ipsec tunnel and they have a fixed config. I’ve been troubleshooting with one of their tech support guys for about half an hour and it appears that no packets reach their end. At least that’s what they told me after sniffing packets with tcpdump on the ipsec terminating server. I’m a little hesitant to fully believe that since I see the packets go into the SA and since the ipsec connection is fully built up, they should traverse to the other end. Unfortunately I know of no one currently using this facility with an MT device so I have no working config to compare with.

6

Well, I actually solved it at last. I don’t know what the problem was, I rebuilt the IPSEC config from scratch and poof, it started working. No config difference compared to what I’ve shown earlier, that I know of. Weird.