On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote: > Because I had a working L2TP server setup on $L2TP, I was not going to > go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf > > ike passive esp transport \ > proto udp from egress to any port 1701 \ > main auth "hmac-sha1" enc "3des" group modp1024 \ > quick auth "hmac-sha1" enc "3des" group modp1024 \ > psk "MYSECRET"
As an aside, you should avoid use of 3des because it is effecively plaintext. There are ways to make even Windows clients use actual crypto with IPsec if needed, though last I checked it could not be done from the GUI but required powershell commands. (I don't have a URL handy, sorry, but this information wasn't very hard to find when I needed it.) > Now I want to move the machine to a new site behind a new OpenBSD firewall, > say FIRE. The difference is that now, $L2TP will have an unroutable address, > say 10.200.100.200, or $L2TPI, as the IP on its external interface. It will > obviously have an external address, $L2TPX, but that will be exposed through > FIRE, the external firewall. I want to binat from L2TPX->L2TPI. > Any suggestions on what I have done wrong or what I need to do right. You could try to pin-point the problem a bit more, starting with diagnostics at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc. I suspect getting IPsec SAs going with both peers behind NAT is tricky. I believe it should be possile in theory but I cannot confirm whether our implementation can do this easily. It will certainly involve UDP traffic since AH/ESP cannot pass through NAT. If your IPsec SAs already work for other traffic, but npppd won't work, that would imply that npppd has a limitation related to NAT; perhaps it encodes the end-point IPs it is seeing in the L2TP protocol, which would not match the actual layer 3 addresses used by IPsec?
