[Swan] net-to-net for road warriors

[Paul Wouters]

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)
>        left=orion.example.com
>        leftsubnets={192.168.1.0/24,68.195.193.40/29}
>        leftid=@orion
>        leftrsasigkey=0sAwEAAdAb4rdETczxNrLeBnheg2i...
>        # dynamic IP (remote office)
>        right=wyckoff.crabdance.com
>        rightsubnets={192.168.11.0/24,192.168.10.0/24}
>        rightrsasigkey=0sAwEAAdH7/d2i5iDV10K4ex1bc3fOg7JOS0M...
>        rightid=@wyckoff
>        auto=start
>        rekey=no

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:
> https://drive.google.com/file/d/1Z2rC48dF_MoJ7YgRA4ugAnkBTP8nAvTe/view?usp=sharing

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.

Paul