IPSec Site-to-Site Issue

RouterOS General
1

Hi,

I’m having a problem with a site-to-site VPN connection between two RouterOS devices, both running 6.29.1.

I can only initiate a VPN connection from Site A, but once the VPN is up, traffic flows unrestricted between Site A and Site B. If the SA times out, I can only re-initiate the connection from Site A. For example, if the connection is down and I try to ping a Site A host from Site B, I receive no response, but if I ping a Site B host from Site A, I receive a response and can ping in either direction until the connection times out.

Both routers are configured identically. I don’t know if DPD would help, but I’d prefer to leave it disabled and allow the connections to timeout when not in use.

Also, on one occasion, I had to flush the SAs and kill the remote peer connection before I could initiate a connection from Site A.

Here’s the configuration for each site:

Site A (WAN 1.0.1.0, LAN 10.0.10.0/24)

/ip firewall filter
add chain=forward dst-address=10.0.10.0/24 src-address=10.0.20.0/24
/ip firewall nat
add chain=srcnat dst-address=10.0.20.0/24 src-address=10.0.10.0/24
/ip ipsec peer
add address=1.0.2.0/32 secret=MySecret
/ip ipsec policy
add dst-address=10.0.20.0/24 sa-dst-address=1.0.2.0
src-address=10.0.10.0/24 sa-src-address=1.0.1.0 tunnel=yes


Site B (WAN 1.0.2.0, LAN 10.0.20.0/24)

/ip firewall filter
add chain=forward dst-address=10.0.20.0/24 src-address=10.0.10.0/24
/ip firewall nat
add chain=srcnat dst-address=10.0.10.0/24 src-address=10.0.20.0/24
/ip ipsec peer
add address=1.0.1.0/32 secret=MySecret
/ip ipsec policy
add dst-address=10.0.10.0/24 sa-dst-address=1.0.1.0 sa-src-address=1.0.2.0
src-address=10.0.20.0/24 tunnel=yes

Any help would be appreciated.

Thanks,

Rick

2

Are you allowing UDP port 500 and IpSec packets on the Input chain on both ends?
Both sides need this:

add chain=input dst-port=500 protocol=udp src-address=1.1.1.1
add chain=input protocol=ipsec-esp src-address=1.1.1.1

Obviously, change the “1.1.1.1” to the Public IP of the Other router. This will allow the both Phase 1 and Phase 2 packets to enter the router. From there the Forward rules and NAT takes over.

For a less secure solution…

add chain=input src-address=1.1.1.1

or

add chain=input dst-port=500 protocol=udp
add chain=input protocol=ipsec-esp

#1 allows Ipsec VPN from only the trusted device. #2 allows anything from that trusted device. #3 allows Ipsec from anywhere. All three work, but #1 is the most secure. #2 trusts that the remote network is completely safe. #3 opens you up to brute force attack.

3

David,

Thanks for your suggestions. I’ll give them a try.

If the firewall rules are necessary, why is it working at all without them? And why can I initiate a connection in one direction?

Any thoughts?

Thanks,

Rick

4

Maybe one system has an error in the firewall and is allowing everything?
The default is that a rule that matches state ESTABLISHED allows traffic.
This means that replies to outgoing traffic work. So from a router configured like that you can make outgoing IPsec
connections. Apparently the other router allows them in. But the reverse may not be true when there is no firewall
rule as described above.

5

It’s allowing one way because one remote end is passing the IPsec. the other is not, but it IS passing established. But do keep in mind, make sure you Established rules are above your other accepts. it will lighten the load on the CPU.