[Swan] net-to-net for road warriors
paul at nohats.ca
Sat Jan 26 03:58:35 UTC 2019
On Fri, 25 Jan 2019, Alex wrote:
> The dynamic IP does have a hostname that travels with any IP change
> (courtesy of freedns.afraid.org), so this should mean I can use left
> to mean local (orion) and right to mean remote (wyckoff) on both
> sides, keeping the names the same on both sides, correct?
Yes, you can do that.
> It turns out the last three days that were spent making this work, and
> likely the problem I was having back in October, was all due to this
> bug you identified involving using --output to help it find its keys.
I'm really sorry you lost so much time over that bug :(
I've updated the documentation for now until we have resolved it.
> Now that I'm able to reliably build tunnels, I feel like now I can
> actually work on how best to configure it.
> The tunnel is built, but I cannot reach either side from the other. I
> can ping wyckoff from orion but not vice-versa, and I cannot reach any
> of the internal networks from either endpoint. I'd like to be able to
> reach each endpoint from the other, as well as the private networks
> from the alternate endpoints.
Are you sure all tunnels came up? Look with "ipsec whack --trafficstatus"
> Now that we've established it's really just a site-to-site VPN, it
> seems the config would be very simple, but it's not working right. Can
> I ask you to again review my config to identify what I'm missing?
> conn wyckofftun
> # VPN gateway with static IP (local)
> # dynamic IP (remote office)
that looks right, but remove rekey=no because you can now rekey because
there is no more %any
> I'm not sure what other info I can provide. Here is ipsec barf:
all the tunnels seem to have come up, so likely this is now related to
NAT or MASQUERADING rules. Or forwarding rules, or those nodes not
having a gateway pointing to the VPN server for those remote subnets.
More information about the Swan