Is it possible to setup an IPSec tunnel to use a specific public address on a WAN interface that consist of a "/29" subnet (i.e any of the 5 public IP addresses) ?
I'm asking since we had some issues with IPsec and the only way to resolve the problem was to pick to the lowest address from the public subnet (Pref. Source according to the routing list). The tunnel is established correctly but cannot pass any packets since the remote peer gets pref-source from the sending side as return address i.e the outbound address = pref-source.
Well, thats what we tried. But the outbound ip address always defaults to Pref Source i.e first usable address in the subnet.
Since you have to use “accept srcnat Src.Addresse Dst.Adresses” as the first entry to bypass any further NAT-traversals, how exactly did you manage to force the outbound ip address to be anything else?
Instead of a direct IPsec tunnel, use GRE over IPsec or L2TP over IPsec to establish a tunnel, and
route your LAN traffic via that tunnel. That will end all your problems with NAT avoidance etc.
Dumb questions -just to be sure:
Did you specify that desired address as local-address in the peer definition?
Is that address actually really assigned to the router?
I have a couple of IPsec tunnels running here with multiple WAN addresses and they’re running just fine as expected…
Hi! Thanks for the suggestion, but In this case it’s not the NAT avoidance that is the main issue, but rather the ability to pick an arbitrary outbound ip address in a subnet for a specific tunnel.
Ok, so if I understand you correctly pref-source is the only way you can control the outbound address for a IPsec tunnel. So in case you have a “/29” subnet defined for your WAN, then you need to assign pref-source for every indivual address in the subnet that you want to assign as an outbound address for a specific tunnel.
But for a “/29” subnet you only have one pref-source in the routing table, right? How do you solve that, what about using “/32” for each subnet ip or is there any other way? Btw, whould a “/32” subnet on the WAN create any side effects or other impacts you shoud be aware of?
Our tunnels are only working when using the pref-source from the WAN-subnet as peer address at both ends. How did you manage to pick any other subnet IP as the outbound address for the tunnel?
Not back in the office, but I have an idea to check in the mean time:
Do you have any masquerade rules configured in /ip firewall nat?
I could bet you have.
Masquerade always uses the lowest address on the interface, no matter what is defined beforehand.
Convert this rule to src-nat (and to-address to your desired address on that interface you wish to use for regular traffic) and then it should work.
We’re using src-nat but I don’t think it matters since you have to define “accept srcnat src.address dst.adress” as the first entry for the tunnel to disable any further NAT-translations.
I wasn’t talking about excluding the tunneled subnets from srcnat but about how outbound traffic is handled by the router - and this does matter.
Anyway - I won’t make it back to my desk before Monday, so I built a working config from scratch here with two routers I have lying around.
And I can confirm that it’s 100% working.
As you can see, on router B, it’s perfectly established:
[admin@routerB] > /ip ipsec remote-peers pr
Flags: R - responder, N - natt-peer
# ID STATE
0 established
[admin@routerB] > /ip ipsec installed-sa pr
Flags: A - AH, E - ESP
0 E spi=0x12CA5BF src-address=172.17.17.2 dst-address=172.17.17.4 state=mature
auth-algorithm=sha1 enc-algorithm=3des enc-key-size=192
auth-key="6e05dcf8e9dcaa9233b76962b5427ad1e109d1b7"
enc-key="8380b7f94995137fcf9d6ea021776e68888fd95e6832f2fa"
add-lifetime=24m/30m replay=128
1 E spi=0x5ACCAAD src-address=172.17.17.4 dst-address=172.17.17.2 state=mature
auth-algorithm=sha1 enc-algorithm=3des enc-key-size=192
auth-key="8856ab852815c05857b119dd3b2e70c705aae721"
enc-key="2fe96ffadcb2413f4c216f71a49110d10e22e2a457278258"
add-lifetime=24m/30m replay=128
So, this is a working IPsec tunnel between two routers with two addresses each on the IPsec-facing interface, peering each other through the higher IPs.
Hope, that helps.
-Chris
Sorry, but I forgot to mention that the tunnel gets established but cannot pass any packets since the remote peer gets pref-source from the sending side as the return address i.e outbound address = pref-source. If possible, please enable logging for protocol 50 (ESP) and check for the same behavior.
Btw, did you manage to ping between the interfaces?
Sorry for the delay- I was a bit more than just busy.
So I tested everything again and it is definitely working and I am passing traffic through the tunnel.
What I noticed is that the tunnel breaks if one or both of the routers do not have a default route. That was new to me too.
You need to have a route that matches your traffic. Normally the default route will do that.
Still I think you should re-consider using a GRE/IPsec tunnel instead of a direct IPsec tunnel.
Things will be much clearer in that configuration and it also allows extension e.g. with multiple subnets and routers.
