When faced with an ISP modem/router, I generally try to switch it to bridge mode and move the PPPoE / DHCP client formerly handled by the ISP hardware to the OpenBSD system instead. This rather simplifies things if you can make it work because then your OpenBSD system has the Internet-facing address and you remove a layer of NAT.
It's unclear to me whether you are stuck with the ISP hardware (but can change it to bridged if you like) or if you are also stuck with it being configured as a NAT router as well so I don't know if this is something you can do. -ken On Thu, Jan 25, 2018 at 6:01 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2018-01-25, Lyndon Nerenberg <lyn...@orthanc.ca> wrote: >> I have an IPsec conundrum I'm trying to solve. Yes, the scenario >> is somewhat absurd; it's also the problem I've been taksed with >> solving, so spare the peanut gallery comments, okay? >> >> >> NET-P <x> GW-Q <-> internet <-> GW-H <x> GW-V <x> NET-V >> >> NET-P is 10.0.2.0/24 >> NET-V is 10.0.11.0/24 >> >> GW-Q is an OpenBSD host with fixed addresses 10.0.2.1 (inside) and >> 1.2.3.4 (internet). >> >> GW-H is some random ISP cable/DSL modem that NATs everything behind >> it, with a random external address. (I.e., assume DHCP on the >> "internet" side.) >> >> GW-V is an OpenBSD host. It has a variable upstream address obtained >> from the back end of GW-H (DHCP). On the other side, GW-V presents >> 10.0.11.1 to NET-V. >> >> The goal here is to establish an IPsec tunnel that links NET-P and >> NET-V together, in the face of all the other nonsense in between. >> >> In the schematic above, '<x>' represents a NAT translation point. >> '<->' is a regular router interconnect. >> >> I have tried setting up an IKEv2 passive connection from GW-V to >> GW-Q (connections in the other direction are impossible), but I'll >> be damned if I can figure out how to specify the SA associations >> and ESP flows on GW-V, given the lack of fixed addresses on the >> upstream sides of GW-V and GW-H. (Or in the other direction, for >> that matter.) >> >> Is there any hope this can possibly work? > > That's a pretty standard setup. I don't have an iked one handy to crib > from but ipsec.conf/isakmpd looks like this: > > - natted side > > ike dynamic esp from $natted_side_net/27 to $other_net/21 \ > peer $remote_external_IP \ > main auth hmac-sha1 enc aes group modp3072 \ > quick enc aes-128-gcm group modp3072 srcid myname > > - side with real ip > > ike passive esp from $other_net/21 to any \ > main auth hmac-sha1 enc aes group modp3072 \ > quick enc aes-128-gcm group modp3072 srcid othername > > iked should be similar, use "ikev2 active" on the natted side, "ikev2 > passive" on the static-ip side. > > Watch out for "nat helpers" on GW-H that try to fix things up but actually > break them but there aren't usually problems these days. > >
