On 2020-04-03, Matt Schwartz <[email protected]> wrote: > I think as long as one side of the tunnel is not doing NAT then you would > be okay.
IPsec copes with NAT on both sides as long as the UDP ports (500/4500) are port-forwarded on one side, Then the ethernet tunnel (etherip bridged to the relevant network interface is usually simplest) can run between private addresses passed over the tunnel. >> On Wed, 1 Apr 2020, at 18:47, Tom Smyth wrote: >> > Gre is great and fast and a hell of a lot faster than OpenVPN... >> > However and it is a Big However... >> > Gre does not typically work Across NATs GRE works across IPsec tunnels ok though, giving a way to sidestep NAT. (GRE *can* work across NAT in some circumstances). But IIUC the OP needs an L2 tunnel, so that's normally etherip/egre/eoip bridged to an etherneg interface. etherip is usually simplest. (I think it's also possible to use tun(4) in L2 mode, bridged to an ethernet interface, and forward it via ssh tunnel forwarding - this is easier in some ways but will be slower) It will need a system each side that can use compatible ethernet tunneling mechanisms (and it's easier if these boxes use the same software e.g. OpenBSD both sides so you aren't dealing with learning two different implementations). The general approach is to configure private (e.g. RFC1918) addresses on "dummy" interfaces each side (e.g. 172.18.123.1/30 and 172.18.123.2/30on vether or loopback interfaces) and configure an IPsec tunnel to pass traffic between those addresses (e.g. "ike esp from 172.18.123.1 to 172.18.123.2 peer 11.22.33.44 local 22.33.44.55 main auth hmac-sha1 enc aes group modp2048 quick enc aes-128-gcm group modp2048 srcid somename dstid othername" for ipsec.conf, and copy local.pub from the "somename" side to pubkeys/fqdn/othername on the other side and vice-versa). Get the VPN working so you can ping between those private addresses first (ignore etherip until that works), when you know that side of things is OK then you can use them as endpoints for the etherip tunnel. Don't forget sysctl net.inet.ip.forwarding, and all the network packets involved will need to make it past PF rules.
