I have set up an IPsec tunnel between two of my routers that are on completely different networks. It was a bit of a hassle but I managed to get a connection between them (PH2 State says established).
Both routers have NAT rules allowing the incoming connections from each other, as well as IP->services (ssh, www, www-ssl) allowed from each others networks. I CAN ping router 2 from router 1 (I get a response normally) but I can’t SSH into it or access it’s GUI (default gateway address).
From router 2 I can’t ping router 1 (don’t get a response) although the configuration is the same for both and both say they have successfully established IPsec tunnels to each other.
Awesome, I can access the router 2 from router 1 now (the one who was pingable). But, the other way around still doesn’t work. Can’t ping at all although the tunnel is established.
Got any other simple, straightforward and beautiful solutions like this one up your sleeve?
Given the symptoms, it looks like a src-nat misconfiguration in the firewall of router 2, or a misconfiguration of the firewall filter on router 1. If this narrow-down turns out not to be enough, you’ll have to follow the hint in my automatic signature right below, for both routers.
Don’t post just what you deem relevant - the mistake is usually in the part of the configuration you don’t post because you don’t expect it to be related.
To be honest, I am not sure what your signature wants me to do
But to update the situation - it’s been resolved.
It has something to do with the IPsec peer configuration and RouterOS version (I think).
So basically, on one router, the SA Src and Dst address fields (public IP of source and destination router) in the policy configuration tab can be entered manually while on the other you can’t. They are automatically taken from the ‘address’ and ‘local address’ fields from the peer configuration page.
The trick is, previously you didn’t have to specify the ‘local address’ field in the peer configuration tab because you could manually enter that in the SA Src.address field. The routers don’t have the same RouterOS versions installed so I suppose that’s where the difference comes from.
Or maybe the devices themselves, since they also aren’t the same?
Anyways, that ‘local address’ field in the peer configuration page is QUITE confusing since it’s not the local address you input there but the PUBLIC address of the router you’re configuring the peer on. Not sure if anyone can follow what I am talking about but hey - maybe it helps someone, since I’ve resolved the issue this way.
That’s because there is not enough space. It should have read “post the output of the /export hide-sensitive command run on the command line interface”…
It’s actually not that confusing if you understand the relationship, and yes, there has been a change between RouterOS versions.
The local-address parameter of the peer may still be 0.0.0.0; this only means that the peer chooses the local address depending on the routing for outgoing initial requests, or that it responds to incoming initial requests coming to any of its own addresses.
In the older versions, the sa-src-address of /ip ipsec policy could also be set to 0.0.0.0; since the sa-dst-address is the same like the peer’s (remote-)address, it was assumed that routing will result in choosing the same local address as the sa-src-address of the policy which it chose for the remote-peer.
In the new version, there is a peer parameter of the policy, which causes the sa-src-address and sa-dst-address of the policy be inherited from the remote-peer (or active-peer if you run 6.45.x) parameters, linked via the peer.
Oh yea, it does make sense to just export the config instead of writing novels. Good tip!
Not sure I completely follow what you are trying to explain, but what I do know is that the tunnel didn’t work without setting the ‘local address’ parameter or the SA parameters on older versions of RouterOS.
It’s confusing to me because if I am setting up a peer on router 1 and I set the ‘address’ field to what the peer will connect (router 2), why do I have to put ‘local address’ also since the router of course knows what it’s ‘local address’ (i.e. public) is. I am just learning all of this and now I know how to set up a tunnel but sometimes it feels redundant inputting the addresses the router should ‘figure out’ by itself.
Most routers have at least two own addresses (one in LAN subnet and another one in WAN subnet), many have several WAN addresses and several LAN addresses. So it makes sense to specify local-address if you want to restrict on which addresses the router will accept incoming IPsec “sessions” when acting as a responder.
For initiator peers, the only scenario where I can imagine there is a need to set up local-address on the peer is in a multi-WAN environment where you are using some policy routing, and the default route points through other WAN than the one you want to use for that peer. In that case, if local-address of the peer is set to 0.0.0.0, the actual local address is taken from the subnet where the default gateway is located. So if you use a routing-mark to actually route the packets to the remote peer through some other WAN, there may be a problem.
First part I can understand, the router can (and basically always does) have multiple internal and external addresses.
I don’t really follow what you said in the second part but as far as this concrete case is concerned - I was doing a test tunnel between the two networks we have in my company environment.
Two different ISPs with two internet uplinks and each with their own router of course with the networks being completely separate. The tunnel I was testing was a tunnel between those two networks (routers).
Maybe there lies the answer to why the local address field was necessary to make the tunnel work. Can’t see it though, I am just happy it works and I know what the steps for setting up a tunnel are
The scenario I was suspecting would be relevant if you had a single router connected via two distinct ISPs, which doesn’t seem to be the case. With a single WAN connection and a default route using that connection, there should be no reason to specify local-address for a peer. So either it’s some bug (what RouterOS version do you run there?), or the change was actually unrelated (which sounds more likely to me, because already before the change, the data transport via the tunnel had been bi-directional as you could log in to one of the routers from the other one and the first one did respond, so both the IKE SAs and the SAs used for payload transportation must have been working well). What didn’t work was just the initiation of the payload connection in the opposite direction. The only way I can see how this could be related to local-address is that you’d use the private IP of the remote peer as the destination IP for the management connection which didn’t work, and the SA would be running in transport (tunnel=no at policy, which is the default) rather than tunnel (tunnel=yes at policy) mode. In that case, choice of wrong local-address may cause what you describe.
Router 2 had the manual input for SA address so I left the local address in the peer tab empty. On router 1 I entered the local address because it didn’t inherit the SA address from anywhere.
I could access router 2 from router 1 but not the other way around. Only after ALSO inputting local address in the peer tab on router 2 it started to work both ways.
Note that you can avoid all that pain by using an explicit tunnel interface like GRE and use IPsec transport to transport the outer tunnel packets.
The IPsec policy then no longer cares about addresses of stuff you send through the tunnel, and all that messing with NAT avoidance is no longer required.
Just add a GRE interface at each end, put an IPsec secret in the definition, put an IP address (from a separate /30 subnet) on each tunnel interface, and
then you can set static routes or even run a routing protocol like BGP or OSPF to automatically add the routes.
This is much clearer because you don’t have the confusion that the entry/exit interface of your site-to-site traffic is the same as your internet interface
(which causes the NAT problems that you have to work around) and you have an explicit interface where you can easily attach firewall rules for site-to-site traffic.
